MapWinUtility assembly not found

Sep 9, 2011 at 11:50 PM

I cannot get the DotSpatial.Plugins.ScriptRunner to compile. It cannot find the MapWinUtility assembly. This Wednesday was when I first cloned the repo and compiled the project. It worked then. But by the next day (yesterday) I started having this problem. I tried everything to ensure my repo clone was done right, but nothing on that front changes anything. I think this is a real problem.

I am doing this in Visual Studio in Windows. Not a Linux issue. (The same problem is reported in Mono, but my tests in Windows are what I base this report upon.)

Since I am new to the project, I may be "doing it wrong". Is there something special that needs to be done in order to create the MapWinUtility assembly before compiling the solution?

Developer
Sep 12, 2011 at 7:10 PM

This plugin depends on MapWinUtility which is part of MapWindow 4. It has not yet been decided what to do about this dependency. The options I can think of are:

1. Include a copy of MapWinUtility.dll in the DotSpatial repository where it can be referenced by this plugin.

2. Include a separate version of the MapWinUtility project source code in the DotSpatial repository.

3. Copy the needed portions of MapWinUtility into ScriptRunner.

I think:

1. would be simplest, we already depend on other third-party libraries that we include as DLLs. Anyone who wants to can get the source code from its native repository.

2. would be very confusing to have two versions of the same project source code in different repositories

3. would be better than 2. but would still have some of the disadvantages of 2. because changes to the copied classes here or in MW4 would be difficult to share back and forth. (Note: clsScripting and clsStrings are the only ones needed, Logger.Msg can be converted into MsgBox)

Developer
Sep 13, 2011 at 7:56 PM

We are looking at including only the relevant portions of MapWinUtility that are needed by ScriptRunner. This still suffers from 2. above.

Sep 14, 2011 at 1:26 PM

I'm sure you have your reasons for choosing #2, but I must warn against code duplication in general. It will result in a maintenance nightmare. Think about how you are going to migrate changes from the main repo. No matter how you slice it, it won't be pretty.