I spent part of my morning in .NET hell, a situation that I try to avoid as much as possible. That is the reason I use WX in the first place!

I use a .NET library to convert JSON data to XML data, which will be the topic of a future webinar. But today’s topic is just what it took to get the .NET library to work on both my test machine and my development machine.

The first thing you will find out is that the .NET dll will be in your EXE directory under your project directory on your development machine. However when you publish your site you will also need to place the .NET dll in the C:WebDev19AWP directory. Or whatever directory you current WebDev WAS server installation is, this is where all the WX DLL are loaded for the WAS server. If you don’t include the .NET dll there, you will get an error message similar to this when you try to run the site:

The highlighted details are “Could not load file or assembly ‘file:///C:WebDev19AWPNewtonsoft.Json.dll’ or one of its dependencies. The system cannot find the file specified. File name: ‘file:///C:WebDev19AWPNewtonsoft.Json.dll'”

That is how I determined where the file needed to be located on the server. It is important to read the details of the error carefully, because as you will see shortly, the second issue gives a very similar but slightly different error message.

So placing the .NET dll in the right location on my production WAS server solved my problem and my code now worked on the server. However I was still having issues when testing on my development machine.

At first I got the same type of error as I was getting on the production machine, the only difference is the directory location. When executing in Test Mode, the .NET dll needs to be located in C:WebDev 19ProgramsEngineWindowsAWP, or wherever you WebDev is installed.

Even after placing the file in the correct location, I got what I thought was the same error. But after throwing my hands in the air and pull out a little more of my dwindling supply of hair, I noticed that the error was slightly different.

Although at first glace this looks like the same error, on closer inspection you will notice that it says something about Operation not Supported, and the details contain this information “System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.”

If you go to that Microsoft article or start Googling related terms you will find that M$ (as they often do) has changed something in the latest versions of the .NET framework that break things that previously worked. In this case they have added an extra level of security when running .NET dlls remotely. What seems odd about this is of course, our DLL is not being ran remotely, it is located on the same machine. Well it turns out that, any file downloaded from the internet is marked as such and treated as being remotely executed even though it is a local file.

The referenced Microsoft Article and most Googling discusses adjusting the .NET config file to enable the loadFromRemoteSources flag to get around this issue. I tried a few different methods to accomplish this but never had any luck.

But I finally found an article that shows another way to get around the issue. Remember the files downloaded from the internet are marked as such and treated as being remote files, if we right click and look at the properties of the file, we see were the file is blocked as a remote file.

Simply click on Unblock and press Apply. Now the file will be treated as a local file, and I am finally able to run the .NET dll both on the Production and Development machines.

As mentioned a future webinar and article will cover what I use this particular .NET dll for. It has made working with Webservices that use JSON data so much easier!!

Now, back to your regular schedule program….

• Quick Tips
• WEBDEV