Error installing package. FK_KEY constraint

Guest

What is the version of the package that is causing the problem? This could happen if it's not a valid semantic version - in particular one with leading zeroes (such as 1.02.10 instead of 1.2.10). Numbers like this are supposed to be parsed and normalized before being used in the db, but it's possible that's not happening here.

If this is the problem, we can send you a SQL script that will patch the Packages_CreateOrUpdatePackage stored procedure.

tbl_5153

What is the version of the package that is causing the problem? This could happen if it's not a valid semantic version - in particular one with leading zeroes (such as 1.02.10 instead of 1.2.10). Numbers like this are supposed to be parsed and normalized before being used in the db, but it's possible that's not happening here.

The version is of the format: yyyy.mm.dd.bb

In the exact case: 2014.11.05.02

As stated earlier this exact package has been imported into the old feeds without any issues.

tbl_5153

And as extra info.
Proget is updated to 3.3.4 with same issues.

Guest

I've emailed a SQL script you can try to the notification address you provided to this forum. Let me know if it helps.

tbl_5153

I've emailed a SQL script you can try to the notification address you provided to this forum. Let me know if it helps.

I have responded via email, but for future reference i am also going to respond here.

Script ran, modified 2 rows, and i was now able to import the package using the Bulk import folder option.

However the package is not showing up in a correct manner in the Proget view.
as can be seen in this image on dropbox:

Image on dropbox

tbl_5153

However the package is not showing up in a correct manner in the Proget view. as can be seen in this image on dropbox:

Dean was able to send me yet another SQL script that resolved this issue.

Dean/Proget team.
Thanks for your fast an consistent help in this matter.

I regard this issue as resolved, but to fix it some manual database steps are required, and they are not really nice to do on production servers.
I guess a hotfix might be in store for this.

Kind regards
Thomas

Guest

Thanks to Thomas for his help in figuring this out. We will be including a fix for this issue in v3.3.5.

If anyone else encounters this issue and we have not released 3.3.5 yet, email us at support -at- inedo.com and we will send you the patched SQL scripts.

Note that this issue only affects versions 3.3.0-3.3.4.

Guest

Upgraded to 3.3.3 to 3.3.11 and noticed that now ProGet just removes leading zeros from the package name. So 1.2.0102.175 becomes 1.2.102.175. Is it possible to keep the name as is?

Guest

It does remove those zeros for internal storage, but it should return the original version in queries and as part of the file name when you download the package.

Guest

Hi Dean,
That did not work right after the upgrade for some reason, ProGet was creating packages without leading zeroes and our deployment step was failing as it wasn’t getting the right package. Now after few days it seems to work, strange. Well, all good while it works.

Minor thing that I noticed though, when you select package in ProGet UI, it still shows version number without leading zero. That’s in the section where it provides command examples:
YourPackage 1.2.0105.105

To install YourPackage from the command line, run the following command:
nuget install YourPackage -Version 1.2.105.105 -Source http://YourServer:10030/nuget

Not a biggy, but might get some people confused.

Guest

It could be that the versions were fixed up when a package cleanup ran - happens every day by default, but may not have been immediately after the upgrade.

Thanks for letting us know about the zeros missing from that page; we'll add an issue for this to get fixed in the next release.