Mar 23, 2012 at 2:56 PM
Edited Mar 23, 2012 at 3:01 PM
Thank you very much for your prompt reply. Less than an hour after posting my message I found the solution - though not the answer. I still have no answer, but hey, at least it works. And I must say clearly and loudly: It was not your (MapWindow
(Also, thank you for mentioning the missing method. I "fixed" it by using latest versions of DotSpatial DLLs. In fact, there was another exception for which I found no workaround, at the time, but which seems to be now solved: Line 95 in Program.cs,
If I remember well, the message was that PackageManager was not found. I just outcommented the line and everything worked OK.)
Anyway, the main problem of this discussion is related to some kind of security policy. When I download a zip file from the internet using e.g. Firefox, NTFS associates to it some funny attributes that mark it as untrusted (in fact, the archive
is considered "blocked", although I cannot comprehend what is blocked there...). DLLs extracted from such an archive will have the same lousy level of trust. .NET 4.0 needs an explicit setting for loading those assemblies, with a technique called "sandboxing"
(personally I did not manage to make it work. Microsoft
tells you what XML lines to insert, but fails to mention into which file to insert them.).
The trick is to "unblock" the archive (right-click on the file in Explorer, "Properties", "Unblock"). Or to copy it to a FAT volume and back - it will lose its NTFS-specific attributes. All DLLs extracted from an "unblocked" archive
are loaded normally by any application which consumes them. Alternatively, if the DLLs were extracted before "unblocking" the archive, they must be "unblocked" in the same way.
I found out about this in a
discussion from DotSpatial, in a rather unassuming answer to a similar question.
So now I am as happy as I can be. MapWindow.exe works marvelously. All versions of my work start in debugger. I can really focus on my project.
What I still have no answer for is why was it possible to start the application from within VisualStudio2010 for three days, with "blocked" DLLs, and then suddenly not anymore?
What eerie configuration or settings or flags silently changed, so that loading the untrusted DLLs was suddenly not possible anymore?
It's not really important. The essential trick is unblocking the archive / the DLLs.
And then there are the bugs... :D