Posts made by tbl_5153

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.

Following error occurs quite a lot in our Proget server, which is working very nice but has been acting up after the latest update.

Message:

Error installing package: 547`16`0`Packages_CreateOrUpdatePackage`111`The INSERT statement conflicted with the FOREIGN KEY constraint "FK__Symbols__Packages". The conflict occurred in database "ProGet", table "dbo.Packages".

Stacktrace:
at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo) at System.Environment.get_StackTrace() at Inedo.ProGet.Diagnostics.DatabaseErrorMessenger.Inedo.Diagnostics.IMessenger.Message(IMessage message) at Inedo.Diagnostics.Logger.Message(MessageLevel messageLevel, String message) at Inedo.ProGet.Service.DropPathMonitorExecuter.Execute() at Inedo.TimedExecuterBase.ExecuteMethodHost(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.TimerQueueTimer.CallCallback() at System.Threading.TimerQueueTimer.Fire() at System.Threading.TimerQueue.FireNextTimers()

This happens during a migration from the 'old' feed setup to the new structure that has been introduced in the update to 3.3.3.
Im using the bulk migration of packages from the old feeds to the new one, by dumping to a monitored folder.

1. First major issue is that there is no way to reference the error in the message to the offending package in the database. Why not log unique information that allows for finding the entry in the packages table, could be Package_Id and Published_Date. 547160` does not really help much.
2. Can i do something manually?. I guess an entry is missing in the DB because of FK error, but right now i cannot fix it manually since a lot of relevant information is missing in the error message.

Best regards
Thomas

Product: ProGet
Version: 3.3.3

@Brett
I'm the original poster, and we still have issues with the Source server.
It worked for a while, and now we are having issues once more, but it is not consistent and therefor hard to track down.

Now that you say it works, i'm wondering if VS is simply using your local sources, here i'm assuming that the package is build from a project that is local on your machine.
As far as i remember the PDB contains information on the original filepath of the source, thus VS can actually find your local source.

This has been evident on several occasions in our teams, since we could alter the source we were stepping into and the source was then altered in the project from which it originated.

This issue is about more than one thing.

Scenario. We have been switching framework versions on our .NET packages and projects to NET 4.5.1

Issue 1:

Packages with a higher framework version can be installed in projecs with a lesser version.

Packages, build for .Net 4.5.1, in the Proget DB now shows.

• Table:[ProGet].[dbo].[Packages]
• TargetFrameworks_text: No value

This means that the package is shown, and can be installed in projects targeting frameworks lesser than 4.5.1. This has been tested and Nuget will indeed install the package.

Issue 2:

Packages with a .NET framework version lesser than the one it should be installed into is not visible in the Nuget Package manager.

Packages that has a value in the:

• Table:[ProGet].[dbo].[Packages]
• TargetFrameworks_text: Here there is framework info

are not available in the Nuget package manager if the project that it should be installed into does not have a version that is in the listing in the TargetFrameworks_text

This is problematic since .NET can easily use assemblies with a lesser framework version. Installing via the Nuget package console works fine, and the package is installed and works as expected.

We are caching some packages from the Official Nuget feed and those packages are not visible when looking at the Proget feed but can be easily found on the NuGet feed. This shows that the problem seems to lie in Proget and not NuGet.

Product: ProGet
Version: 2.2.13

Publishing a package containing source and symbols, packaged using the Nuget -symbols command, does provide symbols but not source stepping.

Visual Studio will only step into local code.

It is my understanding that Proget strips a Symbols package for the PDB and Source files, and i assume that it then updates the PDB sourcefile paths to reflect the source server setup.

If this is the case it does not work.

It that is not the expected behavior of Proget, then how do i manipulate the PDB to reflect the Proget source server, so the Source code is available for stepping.

nb. Proget claims that source and symbols are available for the package.

Thomas

Product: ProGet
Version: 2.2.13

Tod's answer gave me something to look for.

The IIS 7.5 did not have ISAPI enabled so after doing that the proget site worked as a charm.
Definitely something that is missing in the documentation!

For further reference see below:

To enable ISAPI in the IIS look here: http://www.iis.net/configreference/system.webserver/security/isapicgirestriction
at the part

Setup

The <isapiCgiRestriction> collection is available only after you install the CGI or ISAPI Extensions modules on your IIS 7 server. You cannot install it independent of those features.

WINDOWS SERVER 2008 OR WINDOWS SERVER 2008 R2

On the taskbar, click Start, point to Administrative Tools, and then click Server Manager.
In the Server Manager hierarchy pane, expand Roles, and then click Web Server (IIS).
In the Web Server (IIS) pane, scroll to the Role Services section, and then click Add Role Services.
On the Select Role Services page of the Add Role Services Wizard, select CGI or ISAPI Extensions.

If the Add role services dialog appears, click Add Required Role Services. (This page appears only if you have not already installed any prerequisite role services on your server.)
On the Select Role Services page, click Next.
On the Confirm Installation Selections page, click Install.
On the Results page, click Close.

After doing that i restarted and did not have to any further setup. Loading the site just worked.

Inedo should make it much clearer in the documentation that this must be installed in the IIS for proget to work. Just setting the App Pool to Classic is not enough.

Thomas

The App pool is actually set to Classic mode, so that does, unfortunately, not have any influence on the issue.

On a vanilla install of Proget, where it should be hosted in IIS 7.5
the site fails immediately with the following error:

Handler "Wildcard64" has a bad module "IsapiModule" in its module list

Which relates to the following entry in the config:

<handlers>
      <add name="Wildcard32" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="classicMode,runtimeVersionv4.0,bitness32" />
      <add name="Wildcard64" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="classicMode,runtimeVersionv4.0,bitness64" />
    </handlers>

I have confirmed that the dll's defined in the handlers section does exist.
How can this issue be solved?

Product: ProGet
Version: 2.2.13

Hi
To recap for future reference.

To push a package containing symbols and sourcecode the following has been tested and worked fine with nuget 2.8:

1. Create nuget package using: nuget pack foo.csproj -Symbols
2. Alternatively use: nuget pack foo.spec -Symbols

The above command will create two nupkg. The one decorated with the word symbols does contain all libs as well as the sourcecode and PDB files.
You cna check yourselfes by opening hte nupkg in something like winzip or 7zip, since the package is basically a zip file.

3. Push the symbols package to proget.
4. check the package on the feed. If the symbols server is activated the package info will show that symbols and source are available.

Follow the Inedo guide on how to add The Proget symbol server support into Visual Studio.

Food for thought.
My, very quick test, shows me that a package build in the .NET 4.0 framework, of course works fine in a .NET 4.5 project, but i could not use the symbols to debug.
I tried to remove the package, downgrade my test project to .NET 4.0 and reinstall the package.
Now i could debug nicely into the source.
Bottomline. The symbols package and the project that uses it must be on the same .NET version for the symbols to work. Symbols compatibility does, apparently, not span framework versions, even thou the frameworks themselves are backwards compatible.

Thomas

Hi Steve.

Packaging with the -symbols tag does indeed create a package that contains the exact same files as the normal nuget package PLUS source and PDB files.

At least that is what happens when i use nuget.exe v. 2.8

Thomas

Hi Steve

Packaging a project using the -symbols param creates the *.nupkg and the *.symbols.nupkg 'zip' files.
Investigating these seems to indicate that the symbols file contains everything of the normal nupkg as well as the as the 'PDB' nad all of the source.

Am i to assume that i should/can simply push the symbols package and get excatly what you describe as:
or just use a single package that has both

Thomas

Proget 2.2.7 Build 3 has a recurring problem with files that are being used by another process.
see error:

Package Indexing Error
Feed	Staging
Package	ifmviewer.core.1.0.0.nupkg

Message	The process cannot access the file 'd:\ProGet\Packages\Staging\ifmviewer.core.1.0.0.nupkg' because it is being used by another process.
Date	10-12-2013 16:37:46

Stack Trace	 at 
System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at Inedo.NuGet.Packages.NuGetPackage.ReadFromNupkgFile(String fileName)
at Inedo.ProGet.Extensibility.PackageStores.DirectoryPackageStore.TryReadPackage(String fileName)

Proget is installed on it own dedicated server.

Hi Alex
My simple response would be.
Follow all dependecies.
ProGet should get all possible version variations of the dependecies.

/Thomas

Tested with following packages when trying to 'Pull To Proget' with dependecies:

Failed:
Burrow.Extras 1.0.22

No Failure. Pulling with dependecies worked:
Burrow.NET 1.0.22
ServiceStack 3.9.70
Apache.NMS.ActiveMQ 1.6.0

It seems to be isolated to Burrow.Extras 1.0.22
That is quite wierd

When pulling a package, with dependencies, into a proget feed from a connector, proget fails.
Error:
System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.InvalidOperationException: Sequence contains no elements
at System.Linq.Enumerable.First[TSource](IEnumerable1 source) at Inedo.NuGet.Packages.Dependencies.PackageDependencyResolver.<>c__DisplayClass6.<ResolveDependencies>b__2(CandidateSet d) at System.Linq.Enumerable.WhereSelectEnumerableIterator2.MoveNext()
at System.Collections.Generic.List1..ctor(IEnumerable1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable1 source) at Inedo.NuGet.Packages.Dependencies.PackageDependencyResolver.ResolveDependencies(IPackageDependencyQueryable feed, IEnumerable1 packages, DependencyResolutionOptions options)
at Inedo.NuGet.Packages.NuGetFeed.GetAllRequiredPackages(IEnumerable`1 imports, DependencyResolutionOptions options)
at Inedo.ProGet.WebApplication.Pages.Packages.PullFromRepositoryPage.<>c__DisplayClass20.<CreateChildControls>b__18(Object s, EventArgs e)
at Inedo.Web.Controls.ButtonLinks.PostBackButtonLink.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.HandleError(Exception e)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Just pulling the package itself without dependencies works fine.

Proget info:
Version 2.2