How about simplifying the stuff in the Download?

Coordinator
Nov 29, 2010 at 11:44 PM

Hi guys. I've just downloaded the latest recommended release zip file and see that there is a lot of stuff in there that may not need to be there and might confuse potential downloaders. What do you think about removing these files from the release:

".pdb", ".exe.config", ".exe.manifest", ".vshost.exe", ".vshost.exe.manifest", 

Are any of these necessary for someone using the DLL's in their own apps?

Are there any other suggestions on how to make the download more approachable for a potential user of the DLL's who will not be compiling it themselves?

- Dan

Developer
Nov 30, 2010 at 12:01 AM
vhost, delete

.config keep...
.pdb (debug. suggested, since the DLL's are for developers; more unit tests, and I would say no)

think that the manifests have to something to do with code signing.

On Mon, Nov 29, 2010 at 4:44 PM, danames <notifications@codeplex.com> wrote:

From: danames

Hi guys. I've just downloaded the latest recommended release zip file and see that there is a lot of stuff in there that may not need to be there and might confuse potential downloaders. What do you think about removing these files from the release:

".pdb", ".exe.config", ".exe.manifest", ".vshost.exe", ".vshost.exe.manifest",

Are any of these necessary for someone using the DLL's in their own apps?

Are there any other suggestions on how to make the download more approachable for a potential user of the DLL's who will not be compiling it themselves?

- Dan

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com@discussions.codeplex.com

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


Developer
Nov 30, 2010 at 2:17 AM

We can try to clean it up a bit.  I was experimenting with publishing a ClickOnce release for getting a version of MapWindow6 that would be easy to download (even on computers where you are not the administrator) and support automatic updates.  I was also trying to get it to cooperate with ILMerge and failing badly.  In that process there may have been some surplus files created along the way, or a setting might be toggled to produce them.  The .pdb are portable debug files.  They used to only go in the debug builds but as of either VS2008 or VS2010, not sure which, they started also being created with release builds.  I think this is in part because now days most people "publish" for a finished release, and so the technique we are using is grabbing files that are more typically used as developer build locations for testing performance with and without debug processes being invoked.  The pdb files not only are not needed, but they won't work correctly on a computer with a different directory structure set up.  I will delete the extra files before posting the zip in the future.  We used to be able to take advantage of full auto-build, but at this point the new GDAL libraries don't compile in 3.5 since the bindings appear to be in 4.0.  That means the configuration needs to be different based on framework version which means manually building things and re-configuring, or learning how to ignore specific projects using compiler switches in MSBuild or NAnt, which I haven't had time to investigate yet.  I didn't learn the new post was not 3.5 compatible until late last night when I tried to create the output, so I just built them manually.

Ted

 

Developer
Nov 30, 2010 at 2:32 AM
We can create a build without the debug gunk.

You can create a "click-once" build in the configuration manager, and we can autobuild that

msbuild /property:TargetFrameworkVersion=v3.5

On Mon, Nov 29, 2010 at 7:18 PM, shade1974 <notifications@codeplex.com> wrote:

From: shade1974

We can try to clean it up a bit. I was experimenting with publishing a ClickOnce release for getting a version of MapWindow6 that would be easy to download (even on computers where you are not the administrator) and support automatic updates. I was also trying to get it to cooperate with ILMerge and failing badly. In that process there may have been some surplus files created along the way, or a setting might be toggled to produce them. The .pdb are portable debug files. They used to only go in the debug builds but as of either VS2008 or VS2010, not sure which, they started also being created with release builds. I think this is in part because now days most people "publish" for a finished release, and so the technique we are using is grabbing files that are more typically used as developer build locations for testing performance with and without debug processes being invoked. The pdb files not only are not needed, but they won't work correctly on a computer with a different directory structure set up. I will delete the extra files before posting the zip in the future. We used to be able to take advantage of full auto-build, but at this point the new GDAL libraries don't compile in 3.5 since the bindings appear to be in 4.0. That means the configuration needs to be different based on framework version which means manually building things and re-configuring, or learning how to ignore specific projects using compiler switches in MSBuild or NAnt, which I haven't had time to investigate yet. I didn't learn the new post was not 3.5 compatible until late last night when I tried to create the output, so I just built them manually.

Ted

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com@discussions.codeplex.com

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


Developer
Nov 30, 2010 at 3:15 AM

Good point.  Even though technically you don't have a 3.5 toggle, there is nothing stopping us from adding build configurations that are tailored for the 3.5 build.  I currently have it set up to where the 3.5 framework is checked for in the project file XML and updates the output directories, but those are hidden from the properties page because it is a conditional test that isn't set up by the IDE.  But if we instead just set up a new 3.5 x86 and 3.5 x64 configurations, not only could we control which projects are included in them, but we could have their output path specified in a way that will work with the properties page for the projects.  Thanks for the bonk on the head David.  Like I said, it was late last night when I discovered the issue ;).

As to a click-once for DotSpatial... the question is do we want to do that?  I thought that instant download, skipping security issues introduced by unzipping or attempting to install into the programs path, and automatic updates was perfect for a finished executable application like MapWindow6, but is it right for a development package? Click-once kind of assumes that there is one and only one expected zip file, so we could have other downloads but only one zip file would be the click-once variant.  If you click the download button in a click-once project, you instantly start downloading and installing.  I'm not sure that is the way to go for DotSpatial, but if it was, I'd want it to give them everything.  That is, all four output configurations, even if it takes them longer to download it, rather than have them get one configuration and it not be the configuration they need.  If need be, we could set up DemoMap from one of those configurations as the exe file if we have to have one, just so long as they get all the build assemblies they need.  I certainly hate all the security nonsense that now surrounds zip files downloaded that don't come in a click-once package, but would users know where to look to find the downloaded libraries when it finishes?  We could of course simply post a comment to that end on the site.

What I describe probably can't be done with the built in publish context-menu item in solution explorer but it should be possible to set up a batch file to run MSBuild to create our files and then use Mage.exe to sign it.  Another to-do task is that I hear on the grape vine that open source projects may be eligible to get free verisign certification.  I glanced at their page, but I haven't deciphered where to go to not pay money yet.  I also am more or less clueless about how we as an open source project should treat certification.  It would be nice if when people dowload there was something saying that the library they are getting is coming form where it says it is, and not a Trojan horse from China... or I suppose Greece depending on your interpretation of... nevermind.  Anwyay, it's something to think about in the future.

Sigining seems appropriate for HydroDesktop or MapWindow6, which are designed as more top-level projects published by us.  But is DotSpatial?  Or is DotSpatial open source enough that it should always remained unsigned, uncertified and open to the public.  Or do we pass a certification on like an honored baton.  So for instance I could start the DotSpatial certification, and it would not be made openly public, but if at some point we have someone else that wants to assume the responsibility of creating weekly builds from source, then that person gets the baton of certification.  But only that person would get it.  (Certification is generally only valid for x amount of time anyway).  Also I have never gone through the process, so I currently have no clue what is involved, but it must have some identification confirmation that you are in fact the codeplex author somehow.

Anyway, I'm afraid all this will have to wait for me to get back from sunny Palm Springs, California.  I will be away at ACWA for a couple days, but expect to be back by Thursday evening.

Ted

Developer
Nov 30, 2010 at 1:23 PM

In Release mode, the .pdb files are still very useful, because if you get an exception, you can still get the line number where the exception occurred. No pdb, no line number.

Kyle

From: shade1974 [mailto:notifications@codeplex.com]
Sent: Monday, November 29, 2010 9:18 PM
To: kellison@geocue.com
Subject: Re: How about simplifying the stuff in the Download? [DotSpatial:236457]

From: shade1974

We can try to clean it up a bit. I was experimenting with publishing a ClickOnce release for getting a version of MapWindow6 that would be easy to download (even on computers where you are not the administrator) and support automatic updates. I was also trying to get it to cooperate with ILMerge and failing badly. In that process there may have been some surplus files created along the way, or a setting might be toggled to produce them. The .pdb are portable debug files. They used to only go in the debug builds but as of either VS2008 or VS2010, not sure which, they started also being created with release builds. I think this is in part because now days most people "publish" for a finished release, and so the technique we are using is grabbing files that are more typically used as developer build locations for testing performance with and without debug processes being invoked. The pdb files not only are not needed, but they won't work correctly on a computer with a different directory structure set up. I will delete the extra files before posting the zip in the future. We used to be able to take advantage of full auto-build, but at this point the new GDAL libraries don't compile in 3.5 since the bindings appear to be in 4.0. That means the configuration needs to be different based on framework version which means manually building things and re-configuring, or learning how to ignore specific projects using compiler switches in MSBuild or NAnt, which I haven't had time to investigate yet. I didn't learn the new post was not 3.5 compatible until late last night when I tried to create the output, so I just built them manually.

Ted

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com@discussions.codeplex.com

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

Mar 15, 2011 at 8:09 AM

I'm just curious why you need to have separate assemblies for x86 and x64?  What are you doing that is incompatible between the 2 that you can't just set the assembles to "AnyCPU"?

Developer
Mar 15, 2011 at 5:38 PM

The separate assemblies for x86 and x64 are required for raster support. The support of formats such as GeoTiff, and ArcGIS Grid is currently only possible in DotSpatial using 'GDAL Data Extension'. Internally the 'GDAL Data Extension' uses some unmanaged code so it must be handled separately for 'x86' and 'x64'. The 'x64' release is actually built as 'AnyCPU'. If your custom application doesn't require raster support, than you should use the 'x64 (== anyCPU) release and build your application as 'AnyCPU'.

Mar 15, 2011 at 5:46 PM
Edited Mar 15, 2011 at 5:48 PM

Excellent.  Thanks for the information.  I would assume I can pick the x64 to work with for development, and then install the correct version when installing on a x86 OS client?