Installer does not overwrite existing DLL's.

[ArjandeBruijn]

Basically it is already in the subject, I am using installers for my home made extension that are derived from existing other extensions. 

However, when I run my setup file, it does not replace DLL's that are in C:\Program...\extensions. Even when I run the setup file as administrator. 

And worse, the setup file does not give a warning that it is not overwriting dlls so I'm never sure what dlls are actually running.

Any ideas? My colleague Brian said that there used to be flags set in the installation files with 'allow_overwrite'.

thanks

Arjan

[James Domingo]

Hi Arjan,

 

Are you setting the version for your extension's assembly file (i.e., *.dll file)?  If not, then it defaults to 0.0.0.0, which is a problem documented in this issue:  https://code.google.com/p/landis-extensions/issues/detail?id=24

 

The installer software uses an assembly's version number to determine whether to overwrite a copy of the assembly that's already installed on the system.  It will only overwrite the assembly if it is installing a newer (higher) version of the assembly.  In other words, it'll only replace an assembly file if it's being upgraded to a newer version.  It prevents accidental downgrading of an assembly to an older version.

 

That's why having the assembly's version remain stuck implicitly at 0.0.0.0 is a problem.  Even if a developer changes the code in his assembly, its version number has not changed.  So the installer software can't tell that it's a new version of the assembly, and will not overwrite the previous version of the file which also has version number 0.0.0.0

 

To address this problem with 0.0.0.0 version numbers on all the versions of their extensions, some developers used flags to tell the installer software to forcibly overwrite an assembly.  Basically, it ignores version numbers, and overwrites the assembly.  The problem with using these flags is that they make it possible to downgrade an assembly accidentally.  If the assembly is a library shared among multiple extensions, then this approach allows the installation of one extension (with an older version of the library) to break the other extensions.

 

Jimm

--

James Domingo

jdom...@green-code.com

[ArjandeBruijn]

Yes I did not have a version file set. 

This is far from ideal though, because I am working with a few people who are trying my code and I am giving out setup files to them, receive feedback, and give out a new setup file. The setup file ensure that they get the whole package each time (example+ user guide+dlls) so it is not enough to just have them replace DLLs. Moreover, the setup procedure does not even give an error when the installation is unsuccessful.

What do you think about this solution pasted below from  http://stackoverflow.com/questions/356543/can-i-automatically-increment-the-file-build-version-when-using-visual-studio?

-----------------------

In visual Studio 2008, the following works.

Find the AssemblyInfo.cs file and find these 2 lines:

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

You could try changing this to:

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]

But this won't give you the desired result, you will end up with a Product Version of 1.0.* and a File Version of 1.0.0.0. Not what you want!

However, if you remove the second of these lines and just have:

[assembly: AssemblyVersion("1.0.*")]

Then the compiler will set the File Version to be equal to the Product Version and you will get your desired result of an automatically increment product and file version which are in sync. E.g.1.0.3266.92689

----------------------------------------------

It gives somewhat strange version numbers, but they will increment automatically with each built. I tried it and the DLLS are overwritten for new builts now.

[Jimm Domingo]

Glad to hear you got it working, Arjan.  Your approach is the most appropriate I think.  I've used it with other L-II components (core framework, console interface, harvest extensions).  I've added a page to the developers wiki documenting this approach: 

  http://code.google.com/p/landis-extensions/wiki/AssemblyVersions

It describes what those "strange" default values for the 3rd and 4th parts of the assembly version numbers, and how they make our installers work properly.  If there's anything that can be improved or added, just let me know or please feel free to edit the page yourself (permission to modify the repository includes the wiki too).

Jimm

[ArjandeBruijn]

Jim,

I made a few additions to the wiki. Note that if the project does not have a file called AssemblyInfo, you need to add it through project properties. And in order to do so, you also need to enter project information like company and copyright. Right now I suggested in wiki to keep these empty. But I don't know about legal issues so please edit the wiki if we should enter something there. 

My addition:

=========================================================================================================

For Visual Studio: Check if your project has a folder contains a file AssemblyInfo.cs (usually in a subfolder called properties). Open it if it does.

If it does not, then go to project properties -> Application -> Assembly information, a popup screen will appear

Add title (for example): Landis.Library.Succession

Description: can be empty

Company: can be empty

Product: can be empty

Copyright: can be empty

Trademark : can be empty

Assemblyversion: See below

Fileversion: all zeros

GUID leave empty

[Brian Miranda]

As I went to implement this change in some other projects, I saw a discrepancy with how I have been treating version numbers.  Generally, I have followed the convention of version numbers being MajorVersion.MinorVersion.BugFix.  So we have a few extensions out there with 3 digit versions numbers when bug fixes have been released.  The method that has been proposed to automatically increment version numbers uses the last 2 digits of the version number, which means we could then only specify 2 digits (Major and Minor) for our vesion numbers.  If we specify 3 digits and then * for the 4th, the increments only represent a time stamp (seconds from midnight) and not a date stamp, so it would not correctly increment.

 

So, I just want to throw this out there for others to comment on.  Is there value in specifying a 3-digit version number to represent bug fixes, or should bug-fixes be considered minor releases and just do the 2 digit version number?  I don't have a strong opinion either way, but others might see a reason to go one way or the other.  If 2-digit version numbers is the only way to make the automatic incrementing work, then that probably would be the way to go.  But there also might be a different way to do the auto-increment.

 

-Brian

[Robert Scheller]

There are flags that can be set in the Inno Setup installer tool to effectively disregard the version numbers.

For example:

Flags: replacesameversion

This flag will replace the same or older (it looks at the date and version).  

Personally I prefer Major.Minor.BugFix.  More information is always better.

[Arjan de Bruijn]

I was ok with the flags as well, one could also want to downgrade for some reason and that is made impossible with the auto increments.

I found some alternatives, for example with an add-on (http://autobuildversion.codeplex.com/), but nothing as simple as either suggested solution.

--
You received this message because you are subscribed to the Google Groups "LANDIS-II Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to landis-ii-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Domingo]

I'd caution about using those flags to override Inno Setup's default behavior.  That behavior (allowing a file to be overwritten only if it's a newer version) is the default because it's the most common scenario.  Most often, a user is upgrading an extension (i.e., installing a newer version).

 

The user can still downgrade an extension to an older version, by first uninstalling the current version via the Control Panel, then installing the older version.  Although this process is just 2 steps, it reminds the user that she's doing something unusual by explicitly having to remove the newer (current) version.  I consider this an important reminder.

 

Jimm

--

James Domingo

jdom...@green-code.com

 

 

[James Domingo]

 

 

Very good question Brian.

 

There are other ways to auto increment an assembly's version number each time it is built, but none as simple as the "major.minor.*" approach.  I used one of those alternatives with L-II version 5, but switched to the current approach (major.minor.*) with L-II 6.0 because it simplified the build process.

 

I would recommend that a bug fix typically results in a new minor version.  In rare cases, a bug fix might result in a new major version if it requires substantial changes to the code (as in a major overhaul of its structure).

 

I think the best use of 3-part version numbers is for hot-fix releases: critical fixes that replace the official release of a particular minor version.  I updated the version wiki page to include two examples that warrant a hot-fix release (a mistake that was overlooked in preparing the official release's installer, and a security vulnerability).  These (hopefully) are rare occurrences, so hot-fix releases would be unusual.

 

My $0.02,

Jimm

--

James Domingo

jdom...@green-code.com

 

 

[James Domingo]

I need to clarify my earlier point regarding 3-part version numbers; it needs more context.  There are 2 types of version numbers: an extension's version number and its assembly's version number.

 

An assembly version number is a 4-part numeric identifier specified as an assembly attribute.  If one or more of the parts are not specified, the compiler will generates values for the missing parts.  The "major.minor.*" approach is a recommendation for assembly version numbers.

 

An extension version number is an identifier that we humans (developers and users) use to refer specific versions of an extension.  This identifier is what an extension developer enters in the Version field of the extension's info file.  It's the version that users see when they run "landis-extensions".  An extension version is more flexible in its structure; it can contain release information -- for example, "version 2.3 (beta release 1)".  My recommendation for 3-part version numbers applies to extension version numbers.  Typically, extension versions would have 2 parts (major and minor).  A 3rd part would only be added for hot-fix releases.

 

Jimm

--

James Domingo

jdom...@green-code.com