This project is read-only.

DemoGPS build errors

Dec 17, 2010 at 8:06 PM

I routinely "Clean Solution" prior to building DotSpatial because I have gotten into trouble in the past not doing that and then I get the dreaded version mismatch when it tries to bind to assemblies in the solution for the app that is being built on top of DotSpatial.  Anyway, DemoGPS has not been building on my machine for a long time.  I finally got tired of looking at the errors complaining about not being able to find DotSpatial namespace.  I tried removing and readding the references to DotSpatial.Positioning and DotSpaital.Positioning.Forms.  When I did, it warned me about a target platform version mis-match.  Turns out DemoGPS is Framework 3.5 while Positioning and Positioning.Forms are Framework 4.0.  Should DemoGPS Target Framework be changed to Framework 4.0?

Dec 17, 2010 at 10:20 PM
the 3.5 builds have been failing in the build system for a while.

Should we just build them all with 4.0 and be over with it.

On Fri, Dec 17, 2010 at 12:06 PM, kellison <notifications@codeplex.com> wrote:
> From: kellison
>
> I routinely "Clean Solution" prior to building DotSpatial because I have
> gotten into trouble in the past not doing that and then I get the dreaded
> version mismatch when it tries to bind to assemblies in the solution for the
> app that is being built on top of DotSpatial.  Anyway, DemoGPS has not been
> building on my machine for a long time.  I finally got tired of looking at
> the errors complaining about not being able to find DotSpatial namespace.  I
> tried removing and readding the references to DotSpatial.Positioning and
> DotSpaital.Positioning.Forms.  When I did, it warned me about a target
> platform version mis-match.  Turns out DemoGPS is Framework 3.5 while
> Positioning and Positioning.Forms are Framework 4.0.  Should DemoGPS Target
> Framework be changed to Framework 4.0?
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
Dec 17, 2010 at 11:05 PM

Yes

*Sent from my Droid*

On Dec 17, 2010 2:20 PM, "valentinedwv" <notifications@codeplex.com> wrote:
> From: valentinedwv
>
> the 3.5 builds have been failing in the build system for a while.
>
> Should we just build them all with 4.0 and be over with it.
>
> On Fri, Dec 17, 2010 at 12:06 PM, kellison <notifications@codeplex.com> wrote:
>> From: kellison
>>
>> I routinely "Clean Solution" prior to building DotSpatial because I have
>> gotten into trouble in the past not doing that and then I get the dreaded
>> version mismatch when it tries to bind to assemblies in the solution for the
>> app that is being built on top of DotSpatial. Anyway, DemoGPS has not been
>> building on my machine for a long time. I finally got tired of looking at
>> the errors complaining about not being able to find DotSpatial namespace. I
>> tried removing and readding the references to DotSpatial.Positioning and
>> DotSpaital.Positioning.Forms. When I did, it warned me about a target
>> platform version mis-match. Turns out DemoGPS is Framework 3.5 while
>> Positioning and Positioning.Forms are Framework 4.0. Should DemoGPS Target
>> Framework be changed to Framework 4.0?
>>
>> Read the full discussion online.
>>
>> To add a post to this discussion, reply to this email
>> ([email removed])
>>
>> To start a new discussion for this project, email
>> [email removed]
>>
>> You are receiving this email because you subscribed to this discussion on
>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>
>> Please note: Images and attachments will be removed from emails. Any posts
>> to this discussion will also be available online at codeplex.com
>
>
Dec 20, 2010 at 5:38 AM
Edited Dec 20, 2010 at 4:32 PM

Weird - Not sure what’s going on in your DS solution Kyle - the Demo.GPS project is .Net 4.0 in my up-to-date mercurial reversion and it builds just fine even after cleaning. The last version of GPS.NET 3.0 targeted .Net 4.0 but supported multiple .Net versions including the compact framework and thats where DS.Positioning came from. There shouldn't be any compilation errors but there are certainly some warnings though they should only be coming up when you do a clean/re-build of the solution - not on every iterative build.

 DS.Positioning doesn't work currently due to some changes introduced after the initial merge. The original submitted version in DS.Positioning.Compact however does (it is not integrated with DS in any way - it just has the same root namespace). I committed all the available time I had to work out what was broken but unfortunately couldn't get to the bottom of it. It seems to be related to some changes in security attributes but as it didn't occur in the original projects or the version I committed (both of which work just fine targeting .NET 4.0) I'm at a bit of a loss as to why it should cause problems with the current DS version. I'd really like to get it sorted out as soon as I/we can as BigStick and I have frozen the original GPS.NET 3.0 and GeoFrameworks 2.0 projects so DS.Positioning is now their only home! (any security guru's help would be welcomed)

 If the compiler messages are really annoying you maybe you could just unload the DS.Positioning projects in the solution as nothing else depends on them.

[Edit] I take it back - not sure whats going on in my DS solution. I checked out the current tip today for one of my devs and as you quite correctly state the DemoGPS project was targeting 3.5 don't know when or how this happened but as Dan so eloquently put it: "Yes" ;)

Dec 20, 2010 at 7:04 PM

Interesting!  I'm not sure why that one project would have ended up 3.5?  The macro I have is supposed to update every project to whatever framework you indicate.  But somehow you must have ended up with a variant that was set to 3.5.  All projects should be 4.0, even if we are trying to allow MSBuild to create 3.5 versions.

David, the 3.5 builds on your auto-build configuration are most likely are failing because they aren't keeping up with changes to the output project directories and configuration settings that we have been updating, but it is also possible that individual commits won't compile in 3.5.  I routinely find that edits to the 4.0 projects have introduced minor incompatibilities that have to be deliberately fixed before I create the 3.5 builds, so it may not be realistic to have a working autobuild for 3.5 for every single commit to the repository.  My current plan is to continue supporting a 3.5 release in the downloads directory, even if the source code is currently configured for 4.0.

Ted

 

Jan 19, 2011 at 9:09 PM

This was address on January 4 in changeset ace9a7592df1