Hi Ben.
Thank you for the clarification of the problem scope.
Look forward to the fix.

Thank you for the quick response, much appreciated +1

Inedo has excellent support and reacts promptly.

Our buildserver tries to upload new packages to Proget at every build.
If the package already exists with same version then the server responds with http code 403.
In the past it contained a message, so this is a bit more to the standard.
The issue is that it is very hard to know why you get 403 from the proget server.
We know that the buildserver cannot overwrite packages so 403 is not an issue if it was ONLY about overwriting packages rights, and we will allow the job to succeed.
But you also get 403 if you have faulty credentials and for that the buildjob MUST fail.
We think that it should be much more explicit why we get 403 as response from proget so we are able to implement different methods for handleling the response.

It could be as simple as to describe in the body what went wrong or maybe choosing other code - albeit i can appreciate that 403 describes the scenario but in too broad terms.

Product: ProGet
Version: 5.0.10

Hi Tod
Thanks for the fast response.

Since i am not relying on the statistics of Proget i have solved the issue with a bit of work.

• Created new feed that uses new standards
• setup custom feedpath and droppackage path for bulk import
• on the server i located that packages on the filesystem and dumped into the appropiate bulk import folder.
• wait a minute or two and the new feed has all the packages.
• Rename feeds so the new one has the name of the old deprecated.

It is a workaround but it works but again - you loose statistics.
Symbols and Source seem to survive :-D

We have been using Proget for years and Symbols and source server has worked pretty well for our .NET 4.* packages.

We are now building net standard 2.* packages and Proget will no longer serve symbols nor source anymore.

Proget states that Package Source : ProGet Hosted
but nothing is indexed etc.

It relates to https://inedo.com/support/questions/6804 as well.

I have confirmed that packages contains PDB and source files.

Command to build csproj used is:
dotnet pack -c Release --include-source --include-symbols

Is there a plan for supporting source and symbols for these package types?

Product: ProGet
Version: 5.0.7

Trying to upgrade a feed:
This feed uses the ProGet 4.0 schema for NuGet package metadata. It will continue to work indefinitely, but does not support Semantic Versioning 2.0, which recent versions of the NuGet client support.

The upgrade fails because of pretty clear error, Null constraint, but that should not happen - right?
Seems like the upgrade script is not taking care of all the possible scenarios.
Any suggestions as to how to proceed?

Error:

Beginning database transaction...
Database transaction created.
Gathering list of packages in feed...
Found 1642 packages.
Migrating packages...
Migrating ABCpdf 10.1.0.8...
Unhandled exception: System.Data.SqlClient.SqlException (0x80131904): 515`16`2`NuGetPackagesV2_CreateOrUpdatePackage`82`Cannot insert the value NULL into column 'PackageHash_SHA1_Bytes', table 'ProGet.dbo.NuGetPackageVersionsV2'; column does not allow nulls. INSERT fails.
Transaction count after EXECUTE indicates that a COMMIT or ROLLBACK TRANSACTION statement is missing. Previous count = 1, current count = 0.
   at System.Data.SqlClient.SqlCommand.<>c.<ExecuteDbDataReaderAsync>b__174_0(Task`1 result)
   at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Inedo.Data.DatabaseContext.DbResult.<CreateAsync>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Inedo.Data.DatabaseContext.<ExecuteInternalAsync>d__33.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Inedo.Data.DatabaseContext.<ExecuteNonQueryAsync>d__31.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Inedo.ProGet.Executions.MigrateNuGetFeedExecution.<ExecuteAsync>d__16.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Inedo.ProGet.Service.Executions.ActiveManualExecution.<ExecuteAsync>d__7.MoveNext()
ClientConnectionId:dec39986-dc1e-4dcf-9d29-646f03280442
Error Number:50000,State:42,Class:16

Product: ProGet
Version: 5.0.7

Solved by using link by Martin Helgseen
http://inedo.com/support/questions/7217

Thanks

Just upgraded Proget to 4.8.4

First issue.
Get a warningbar in the top stating
Warning: The Inedo Core extension is not loaded, most ProGet functionality will be missing.

Entering Admin mode and navigating to extensions.

• We do not currently use any extensions but since the warning states that the InedoCore is not loaded, and it is an extension itself i think - Ill install the InedoCore Extension.

Steps.

• Under available extensions click the extension: InedoCore
• Click Install in new Modal window
• Installation fails:

Unhandled exception: System.ArgumentNullException: Value cannot be null.
Parameter name: targetDirectory
at Inedo.Common.WebApplication.Pages.Administration.Extensions.OtterDenClient.<DownloadFileAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Inedo.Common.WebApplication.Pages.Administration.Extensions.ExtensionUpdater.<UpdateAsync>d__26.MoveNext()

Product: ProGet
Version: 4.8.4

Hi Tod
That is great news +1
Thanks for the very fast reply and hotfix release, which i look forward to.
For now we have stabilised by loading a backup of our Proget server, rolling back to 4.6.7 so we are good for now :-D

Regards
Thomas

Hi.
We use the free version of proget.
We only host internal packages.

I just updated from 4.6.7 to 4.8.1 and now hell has broken loose.

None of our internal packages has a license since they are by nature internal and we have no need for it right now.
Unfortunately alle our packages are blocked on proget and we have many packages.

How can we solve this quickly - it must/should be possible to allow packages without licenses.

I look forward to hearing from you.

Product: ProGet
Version: 4.8.1

Hello Shane,

You can add this as a script from Admin → Manage Scripts:

param($projectDir, $buildType)

powershell -file $projectDir/Resources/tools/PreBuild.ps1 -projectDir $projectDir -buildType $buildType

Then, from the deployment plan, adding "Execute PowerShell Script" with that script will give you fields for the two parameters.

This is our setup.
On build in JEnkins we create a deployable nuget package that is published to Proget.

We use GitFlow, thus all development not done on master or hotfix, will create a nuget artifact that is published to a feed named Development.

Any code pushed to out Master branch in git will, via Jenkins, create a nuget artifact on a feed named Production.

Problem.
In BuildMaster (from now on named BM), when you setup a workflow you define a Buildstep.
In this buildstep we retrieve the nugetpackage.
But the buildstep is used for all the deployment domain.
We deploy to domains named: Development, Staging, Production.

We want a package on the Proget feed Development to be deployed in the deployment domain Development ONLY.
The deployment domains, Staging and Production, should use the Proget feed Production.

Currently i do not see this as something that is possible, but i am also a BM beginner and we are looking at BM as our Continues Deployment system along with other alternatives .
I really need to know if this is possible or how i can make it work.
Regards
For us this is a very important feature.
Regards

Product: BuildMaster
Version: 4.9.6

Alana.
I have made a pull request https://github.com/Inedo/bmx-windows/pull/30
Thanks for pointing me in that direction.
It was indeed very easy to modify the codebase.

Releasing Proget 4.0 with the new package type sounds nice and will simplify our deployments significantly (event thou i have everything working in Jenkins in regards to creating nuget artifacts and uploading them to proget).

Looking forward for the new Proget :-)

Hi.
We are in the process of determining if Buildmaster is for us.

I have a project that i have set to create an app-pool and website in IIS 7.
That works on the initial run but fails on subsequent runs since the pool and site already exists.

How do i implement some check in the workflow that will check for the ecistance of the pool and site.
Essentially i actually expected that the step in the flow was clever enough to ask the IIS if they already existed and if so simply ignore the step in the flow.

All help is very much appreciated.

Product: BuildMaster
Version: 4.9.6

We kinda have the same issue.
We do not use the default setup for artifacts but use a plugin for Jenkins to export to an alternate destination..
It would be nice if you could set the path of the artifact in the extension.
But the path must be able to contain variables that are resolved at runtime, so it might be pretty difficult.

After using some hours trying to solve the issue ald also looking into the extension source we have chosen to add a buildstep to Jenkins where we use
OctoPack to create a nuget package of the deployable artifact and the upload that artifact to Proget.

Now we have applications in Buildmaster that will get the artifact from proget and deploy from there.

You could also add scripting to Jenkins to trigger Buildmaster every time a job in jenkins has succeeded successfully and then it can automagically deploy, but so far we are triggering deployments manually.

Regards
Thomas

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

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

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

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.

I have now found the package that is creating the issue in Proget.
There is no source nor PDB found in the nupkg package that is being imported.

I properly need to define the feedsetup:

• It is of course Active
• Symbols and source server is activated
• Automatic strip pdb on download is active

I have tried variations of these settings as defined below.
case 1:

• Symbols and source server is activated
• Automatic strip pdb on download is deactivated

case 2:

• Symbols and source server is deactivated
• Automatic strip pdb on download is deactivated

I have tried to following in the databse:
Delete all instances of the package in the [ProGet].[dbo].[Packages] table where the package was referencing the feeds i was trying to update.
I have removed any Symbol references for the package that was also referencing the feeds in question. Table of concern: [ProGet].[dbo].[Symbols]

None of these actions has had any effect

This is turning into a quite big issue where a package can actually not be imported in a feed.
It is also concerning that the packages are actually present in the old feeds (the older standard) where they have been imported fine, with symbols.