New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't change assembly version across patch releases #1681

Closed
mikkeljohnsen opened this Issue Oct 11, 2017 · 8 comments

Comments

Projects
None yet
2 participants
@mikkeljohnsen

mikkeljohnsen commented Oct 11, 2017

Is there any way to use version "3.2.0.0" for the assembly in the NuGet package.

I create RPM packages from that, and then a requirement like "mono(Npgsql) = 3.2.5.0" is created. That makes problems when you update later.

I don't think the DLL version should change for every release, only for major releases. Just like MS dll's they have the same DLL version all the time. Only different for frameworks.

@roji roji changed the title from Assembly Version to Don't change assembly version across patch releases Oct 11, 2017

@roji

This comment has been minimized.

Show comment
Hide comment
@roji

roji Oct 11, 2017

Member

@mikkeljohnsen I don't a particular issue with keeping assembly versions the same, but can you please explain why this is an issue for you?

Member

roji commented Oct 11, 2017

@mikkeljohnsen I don't a particular issue with keeping assembly versions the same, but can you please explain why this is an issue for you?

@roji roji added this to the 3.3 milestone Oct 11, 2017

@mikkeljohnsen

This comment has been minimized.

Show comment
Hide comment
@mikkeljohnsen

mikkeljohnsen Oct 11, 2017

The reason is that I create RPM packages of Npgsql and RPM will create a Provides "mono(Npgsql) = 3.2.5.0" in the rpm package.

When you make an RPM package which requires/compiles agains Npgsql it will see what the package requires "mono(Npgsql) = 3.2.5.0" and it will makes a requirement for that.

Now when Npgsql 3.2.6 is released and the assembly version is changed to "3.2.6.0". Then when trying to update the Npgsql package, the RPM system will say that my app requires "mono(Npgsql) = 3.2.5.0" not nothing will provide that. As the new Npgsql package provides "mono(Npgsql) = 3.2.6.0"

mikkeljohnsen commented Oct 11, 2017

The reason is that I create RPM packages of Npgsql and RPM will create a Provides "mono(Npgsql) = 3.2.5.0" in the rpm package.

When you make an RPM package which requires/compiles agains Npgsql it will see what the package requires "mono(Npgsql) = 3.2.5.0" and it will makes a requirement for that.

Now when Npgsql 3.2.6 is released and the assembly version is changed to "3.2.6.0". Then when trying to update the Npgsql package, the RPM system will say that my app requires "mono(Npgsql) = 3.2.5.0" not nothing will provide that. As the new Npgsql package provides "mono(Npgsql) = 3.2.6.0"

@roji

This comment has been minimized.

Show comment
Hide comment
@roji

roji Oct 11, 2017

Member

OK, I'm quite used to nuget, where this assembly redirect is taken care of immediately. 3.3 seems like the right place to fix this (it would be strange to have 3.2.5.0 and then 3.2.0.0 in the same minor version...) - will you be OK with that?

BTW out of curiosity, can you provide a bit more context on why you're producing RPM packages for Npgsql, rather than going with the standard nuget?

Member

roji commented Oct 11, 2017

OK, I'm quite used to nuget, where this assembly redirect is taken care of immediately. 3.3 seems like the right place to fix this (it would be strange to have 3.2.5.0 and then 3.2.0.0 in the same minor version...) - will you be OK with that?

BTW out of curiosity, can you provide a bit more context on why you're producing RPM packages for Npgsql, rather than going with the standard nuget?

@mikkeljohnsen

This comment has been minimized.

Show comment
Hide comment
@mikkeljohnsen

mikkeljohnsen Oct 11, 2017

That is fine with me.

mikkeljohnsen commented Oct 11, 2017

That is fine with me.

@mikkeljohnsen

This comment has been minimized.

Show comment
Hide comment
@mikkeljohnsen

mikkeljohnsen Oct 11, 2017

The reason for using RPM. I guess is habit. I guess, I could use NuGet, and is also using it more and more.

The program, that we sell commercially, is made of 100+ DLL files/projects. So having to add NuGet packages to all projects, instead of just updating the Npgsql package on the development machine and use that. Is a lot easier.

Even thought we use MonoDevelop for the project, we use command line to compile, since MD is slow as hell to compile and having to check NuGet dependencies for all projects is also very slow.

mikkeljohnsen commented Oct 11, 2017

The reason for using RPM. I guess is habit. I guess, I could use NuGet, and is also using it more and more.

The program, that we sell commercially, is made of 100+ DLL files/projects. So having to add NuGet packages to all projects, instead of just updating the Npgsql package on the development machine and use that. Is a lot easier.

Even thought we use MonoDevelop for the project, we use command line to compile, since MD is slow as hell to compile and having to check NuGet dependencies for all projects is also very slow.

@roji

This comment has been minimized.

Show comment
Hide comment
@roji

roji Oct 27, 2017

Member

@mikkeljohnsen, I just looked at this and things may have changed somewhat. Looking at the 1.1.2 nuget for Microsoft.EntityFramework, for example, I can see the assembly version seet to 1.1.3, and not 1.1.0. In addition, in the new csproj project system the AssemblyVersion attribute is autogenerated rather than set in AssemblyInfo.cs, and there doesn't seem to be an option to make it disregard the patch component (i.e. generate 0). See the csproj targets.

So while I could override the standard csproj mechanism, generating my own AssemblyVersion attribute, it seems that this isn't the way things are done anymore in modern projects... Any comments?

Member

roji commented Oct 27, 2017

@mikkeljohnsen, I just looked at this and things may have changed somewhat. Looking at the 1.1.2 nuget for Microsoft.EntityFramework, for example, I can see the assembly version seet to 1.1.3, and not 1.1.0. In addition, in the new csproj project system the AssemblyVersion attribute is autogenerated rather than set in AssemblyInfo.cs, and there doesn't seem to be an option to make it disregard the patch component (i.e. generate 0). See the csproj targets.

So while I could override the standard csproj mechanism, generating my own AssemblyVersion attribute, it seems that this isn't the way things are done anymore in modern projects... Any comments?

@mikkeljohnsen

This comment has been minimized.

Show comment
Hide comment
@mikkeljohnsen

mikkeljohnsen Nov 10, 2017

I can see here: https://support.microsoft.com/en-us/help/556041 that MS recommends to set the AssemblyVersion to a new version on release.

But I still thing it would make more sense to keep AssemblyVersion=3.3.0.0 and use AssemblyFileVersion=3.3.1|3.3.2 etc.

Only setting AssemblyVersion=3.4.0.0 when new major/minor release.

But if it is not possible then I will try to make RPM behave.

mikkeljohnsen commented Nov 10, 2017

I can see here: https://support.microsoft.com/en-us/help/556041 that MS recommends to set the AssemblyVersion to a new version on release.

But I still thing it would make more sense to keep AssemblyVersion=3.3.0.0 and use AssemblyFileVersion=3.3.1|3.3.2 etc.

Only setting AssemblyVersion=3.4.0.0 when new major/minor release.

But if it is not possible then I will try to make RPM behave.

@roji

This comment has been minimized.

Show comment
Hide comment
@roji

roji Nov 12, 2017

Member

@mikkeljohnsen I can see arguments to either side... But at the end of the day I'd rather go with the default/standard behavior here rather than override it. If a new argument or change comes up I'm definitely open to discuss again though.

Hope you find a way to makes things work with RPM.

Member

roji commented Nov 12, 2017

@mikkeljohnsen I can see arguments to either side... But at the end of the day I'd rather go with the default/standard behavior here rather than override it. If a new argument or change comes up I'm definitely open to discuss again though.

Hope you find a way to makes things work with RPM.

@roji roji closed this Nov 12, 2017

@roji roji removed this from the 3.3 milestone Nov 12, 2017

@roji roji added invalid and removed waiting for answer labels Nov 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment