Whilst working on a proof of concept WCF service I ran into an interesting security “zone” issue which caused me a few headaches for an afternoon. I was moving some code out of a prototype WinForm application into a WCF service to prove and demonstrate the next phase of the infrastructure. The functionality in question reference some custom ‘C’ libraries which had already been proven to run when referenced locally within the Windows application. However moving the same the code and therefore the reference to the ‘C’ libraries into a WCF service resulted in most calls to the library throwing a “Security Exception”. Stepping through the debugger, the issue was clear enough, calling “unsafe” code requires Full Trust but even though everything was running locally the WCF service was showing as “Internet” zone and triggering the security exception. This had me confused for quite a while, I wasn’t hosting the WCF service within IIS (see previous post, no admin rights!), so my only option was the WCFHost application. No searches on Google could find anything related, everything seemed to indicate that in this situation the WCF application should run in the same security zone/context as the calling application – which I had verified was running in Full Trust mode.
My final attempt before calling it a day and going home was to try and register the DLL within the GAC and hope that solved the trust issue. It was only when clicking on “Add an assembly to the assembly cache” I noticed that only two drive letters were listed. The solution I was developing was located on the mapped network drive that didn’t appear in the list. As a quick test I moved the solution onto one of the non mapped drives, recompiled the application and tried again. This time everything worked – developing on a mapped drive had resulted in WCFHost dropping the security level that the code was running under!
As part of his fantastic ‘What is .NET standard‘ presentation at DDD12, Adam Ralph provided an amazing amount of detail in such a short amount of time. One of the most valuable points, which is completely obvious when you think about it, is how you should work with .NET standard when creating libraries. NET standard now comes in a multitude of flavours: currently 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 and 2.0. When starting out . . .
If you’re trying to access a class library (.NET Standard) from a traditional console application (in VS2017 those can be found under ‘Windows Classic Desktop’) you will run into problems; which can feel a little strange for something that was pretty simple in VS2015 and earlier. You can add a reference to the class library project (Resharper will even volunteer to add the dependency / namespace reference if you don’t already have it). But the . . .