This project is read-only.

Framework Versions

Aug 14, 2010 at 7:02 PM
I have discovered that .Net Framework 4.0 projects cannot add references to the control elements from our .Net Framework 3.5 project. It would be ideal if we could re-use the source cs files with only new projects referencing the same code. In practice, however, this may not be achievable and still obtain the benefits of the 4.0 framework. To prevent confusion and unlock the new potential in 4.0, I will be creating two separate directories for the two frameworks. I can't guarantee that both will get updated equally, but at least 3.5 developers are not completely blocked from using DotSpatial.
Aug 29, 2010 at 11:36 AM

You could try using links to source files so that the same file is shared between projects - this may make it easier to keep the projects in sync. Add existing file >>  browse to file >> add as link. You can also modify the csproj file manually to include whole directories or directory trees. 

You may find that you then need to use preprocessor directives to isolate .Net 40 vs .Net 20 code sections but you may be lucky..

Sep 1, 2010 at 4:16 AM

I've used the add link/preprocessor directive method Johndiss recommended before successfully.

BTW If your using ReSharper beware of it automatically removing Using clauses contained in #if #endif blocks used for conditional builds of multiple projects in the same solution or otherwise.

Sep 5, 2010 at 4:00 PM

I think I should update this track with my latest thoughts.  I have discovered that the problem with referencing the 3.5 code from 4.0 was because by default a project starts out using the 4.0 Client Profile, which is a limited subset that does not include System.Design.  So in fact, switching the project to use the complete version of 4.0 enables it to use the 3.5 projects no problem.  I was originally planning on hosting the parallel versions, but Dan has been convincing me we probably need to just embrace 4.0 and not look back.  I think, like with the change from 2.0 to 3.5 that the change to 4.0 is easy enough to do and is free for Express/SharpDevelop users so there is not really a purpose to maintaining the separate 3.5 builds.  As John points out, 3.5 users that are very adamant about staying 3.5 could simply add the source files to a project themselves and deal with any complications that arise.  I worry about trying to sustain links ourselves when eventually code written in the new 4.0 framework will have features that are not back-portable.   Eventually, this will start having problems.  For this moment, I am leaving our 3.5 code as is, until I get a little bit more feedback from the group.  But as it falls out of synch, we will need to make a decision to either A) support a linked system like John mentioned to the updated files (which will eventually fail), or B) just support 4.0.

Sep 7, 2010 at 2:26 PM

FWIW, I vote for embracing 4.0.

Sep 15, 2010 at 9:22 PM

What features of 4.0 are we planning on utilizing now?


VS2010 can be targeted at 3.5

Sep 15, 2010 at 10:15 PM

Just because it can be doesn't mean that's the best option for us.  Also, this is kind of an old post.  Basically my understanding was that everyone that is contributing money to the project has voiced the go-ahead for 4.0 and is already using the new libraries.  After all that, I'm not going to force everyone to switch back to targeting 3.5.  The only discussion point that is still open is whether or not we keep the duplicate C# classes around for Framework 3.5.  If no one here is currently using them, then I don't see any purpose in keeping copies that are progressively further out of synch.  I think the strategy is that we provide the source code, so basically anyone that needs to use 3.5 would be in better shape if they added the latest CS files into a VS2008 project, and built from that, rather than relying on code that will ultimately be months or years out of date.  If, as we roll into the future, we still have not used any notable 4.0 content, then that's great for them.  But in the meantime, if we want to explore the possibilities of memory mapped files, covariant lists, and other marvels of technology, we can, and at that point we simply state that you need 4.0 to run DotSpatial. 

Anyway, if you have votes for keeping the out of synch 3.5 copies around, please post them before this weekend.  After that, you should still be able to access historical content, along with VS2008 solutions and projects using the repository history, but in doing so, you will also see just how many changes we have made since then.

Sep 15, 2010 at 10:47 PM

There is a VS2010 macro, that allows it to easily switch between target framework versions for all projects in the current solution.

cheers FObermaier

Sep 15, 2010 at 11:06 PM

Sorry, trying to do a quick build for Hydrodesktop... and the quick back targeting hack to just use msbuild /tv:3.5 failed.

Unless the fixes are getting merged into the 3.5 branch, then there is not a use of keeping the vs2008 branch around, but Hydrodesktop has not migrated yet... 

But, if you use vs2010, and keep targeting 3.5 until you really need a 3.5 feature... 

If you want to provide 4.0, then we can try the retargeting by using an msbuild script.


Issues found when setting to 3.5 are resource related. Pointers to the refs don't get changed back.

- Forms.Ribbon.icons.resx

- Desktop.Components.AngleControl.resx (had to delete row that references ...AnglePicker)

-  Desktop.Components.Images.resx 

- RibbonTest.forms1.resx

Sep 15, 2010 at 11:21 PM

Ah, good point.  I was originally reading David's comment as "DotSpatial should remain targeted to 3.5 and never add any 4.0 code"  After reading FObermaier's comment, however, it make's me realize that yes, users can download VS2010 Express, and then toggle the target version themselves, build the output, and then use the resulting 3.5 libraries in their VS2008 Standard project.  As voiced in previous posts, eventually this will break, but probably for as long as people need it, this technique will work.  By the time our developers are using 4.0 specific code, the number of developers that have to target 3.5 will be scarce.  So now I am reading David's comments as "Since we aren't currently using any 4.0 code just yet, at least for the time being it is trivial for developers to target 3.5, and so we don't need a separate set of 3.5 libraries, just keep the 4.0 libraries".  Anyway, these are all good points encouraging me to stick with just having one set of files in the repository.

Sep 15, 2010 at 11:28 PM

Ack, so resources don't port back? Hmm.  There are quite a large number of resource files all told.  Is your build hack the same as FObermeir's Macro?  Also, if it gets set using the VS2010 IDE does it still fail?  I think you can change the "Properties" of a project to update.  (Of course maybe it would be simpler to get HydroDesktop to 4.0).



Sep 15, 2010 at 11:31 PM


[15:22:50]: [Project "DotSpatial.Forms.Ribbons.csproj" (default targets):] Icons.resx(123, 5): error RG0000: Could not load file or assembly 'System.Drawing, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Line 123, position 5.
Attempt to autobuild DotSpatial:
(log in a guest)

The msbuild command line is:
msbuild /property:TargetFrameworkVersion=v3.5
Sep 15, 2010 at 11:40 PM

Maybe you would have to set the version to 3.5 for all the projects independently, and then build in the correct order.  I don't know how to use FObermaier's Macro, it sounds like his Macro sequentially goes through the whole set of libraries and toggles the version on each in sequence.  But if you are using the "DotSpatial" solution, the DotSpatial.Forms.Ribbons project is one of the projects, and theoretically VS should be smart enough to build lower level projects first, especially if you use project references, rather than dll references.  It sounds like whatever you have open doesn't have the option to build the Ribbon library as 3.5.


Sep 15, 2010 at 11:46 PM
Edited Sep 16, 2010 at 12:15 AM

That's the autocompile from the trunk. I can do a commit to have the tree compatible with a target to 3.5


Believe me, I did it one project at a time, and the team city build is a better hint that the visual studio error output.

it's only been the ones that are recently edited resx (I believe).


I created a fork, which can be merged.



Sep 16, 2010 at 12:11 AM

Ok, I can confirm that simply changing Ribbon project to 3.5 and building throws errors in the IDE like you mention, so the idea of a quick toggle may not be workable without careful maintenance.  Feel free to commit your changes, (presuming you didn't just delete the new resources but rather did something clever so that the new resources work in 3.5).  But it raises questions about our future strategy since every new change to a resource file anywhere in the project may cause grief for the 3.5 developers.  Maybe it won't be a huge issue if there isn't much resource file updating.  Anyway, it's something to think about.

Sep 17, 2010 at 9:08 PM

I'm all for moving to version 4.0 of the framework. I don't really like the idea of trying to maintain two separate versions of the repository. As it is right now I've got some commits I'd like to make that I'm hanging on to until I can get 4.0 installed on my dev machine so I can make sure they work. I guess I'm going to need to talk to Paul Meems about moving MapWindow 4.x to .NET 4.0 if I'm going to be able to keep maintaining the print layout plug-in, that relies on DotSpatial.

Sep 17, 2010 at 9:27 PM
Edited Sep 17, 2010 at 9:28 PM

Ah!  Good point Brian.  I forgot they were relying on the same code base for printing.  In the meantime though, Brian, the plan is that you commit your changes to the 4.0 version in the repository, and if you need it to be 3.5, you can switch back the target framework and build, or build from the 3.5 fork.  Periodically the 3.5 fork will be updated with the latest 4.0 code, but you can channel the latest 4.0 to 3.5 at any time using compiler switch.  This will be true at the very least until HydroDesktop upgrades in November.  I committed Davids fix to the resources, so there should no longer be any compile conflicts when changing target versions.


Sep 18, 2010 at 5:03 PM

You should be able to submit a patch to the Code (not the project files).



Sep 20, 2010 at 9:51 PM

So I spoke with Paul Meems and it turns out that the next version of MapWindow 4.8 64bit will require .NET 4.0 but the 32bit version will only require .NET 3.5 I'm not too worried about it causing problems now that I looked at it a bit closer. Even if the DotSpatial libraries are compiled for .NET 4.0 the printing code doesn't use any of the new syntax or methods so it should run happily in 3.5 much the way that some of my other plug-ins that targeted 3.5 worked on machines with 2.0 unless they used something that was missing from the earlier framework.

Jan 27, 2012 at 6:14 PM

At this time we are now targeting the .NET 4.0 Client Profile