Cannot run sample application. Not anymore.

Mar 22, 2012 at 4:55 PM

Right, so I downloaded MapWindow and, fixed the references, compiled the solution, started it in VS2010 - and it worked.

Double-clicked on MapWindow.exe - application started with a crash. Problem detail: System.IO.FileLoadException.

Attached debugger, got exception:

"Could not load file or assembly 'DotSpatial.Plugins.SplashScreenManager, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)",

with a remarkable inner exception:

"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 for more information."

Why would I want to use or develop an application which loads an assembly from a network location?!?


I started writing my own classes, compiled, started in debugger, and it worked.

After three days of work, 10 minutes ago the debugger refused to start the application. The error message is the same. The error is thrown in DotSpatial.AppManager, line 344 (function LoadExtensions): "splashScreen = SplashScreenHelper.GetSplashScreenManager();". The only thing I did between the last successful run and the failed run was to add two C# sentences in one of my classes. (VS2010 did not care about them, though: it refused to start the application even after I removed the damn lines.)

So right now I have a MapWindow.exe that would not start by itself, a VS2010 solution with a C# application project that would not start in debugger, and my beautiful classes which are basically useless. The only way out of this situation: redo the first steps, re-create MapWindow folders in a parallel directory, add my classes, cross the fingers before clicking "Debug".

What am I doing wrong? What am I not doing?

Mar 22, 2012 at 8:25 PM

First, sorry about your frustrations. We want users to have a good first experience -- which is not what happened for you.

We actually do expect users that are downloading the zip file presently to run into an error (Method not found: 'Boolean DotSpatial.Controls.MapFrame.CanZoomToNext()') and will be releasing version 6.1.1 to address that this week. A workaround is to download the ClickOnce version.

We've not anticipated having developers try to develop with MapWindow in the way that you are, so I have immediately put up a warning on the downloads page (shown below). MapWindow 6 is a tiny wrapper around the DotSpatial Library and a way for end-users to access the functionality in DotSpatial. We're intending for developers to consume the DotSpatial Library and have created a template to make it easy for you to get started. As well as some documentation: How to Create an Extension

Your extensions will work in MapWindow as well as other DotSpatial based projects.


Are you a software developer?

  • Instead of downloading MapWindow for development purposes. Get started with with the DotSpatial template
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 developers') fault.

(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

Mar 23, 2012 at 3:24 PM

Oh, now I really have to apologize: I should have read the whole text from DotSpatial page, when I initiated the download. It is clearly stated there that unblocking the downloaded archive is a rather good idea...

mudnug, I see you are in charge there as well. I owe you one!

Mar 23, 2012 at 5:11 PM

No problem! I'm glad to hear of your success.