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