You'll need a different path for the ServiceTemp Path. Both Web Site and Service unpack to that directory and load files from there... so there will be a collision.

The default PDB format for the project files was changed from Full to Portable (see https://github.com/dotnet/core/blob/master/Documentation/diagnostics/portable_pdb.md). The portable format is not compatible with the symbol server. To switch back to the old format just add this to a property group in the *.csproj file: <DebugType>Full</DebugType>. You can also override this with /p:DebugType=Full in your build command. Also make sure that the nuget packages are created with --include-symbols --include-source

This was a breaking change NuGet team made in NuGet 3.4 (I think). We did not want to not implement, as the change would impact a lot of our customers who rely on the quirks of "non-normalized" versions. So, as a compromise, the NuGet team implemented a searching strategy in the client to try a normalized version of the number (like 0.0.0.0), and then try non-normalized version (0.0.0) if not found. At this time, you'll need to do the same for your searches; if we ever decide to implement the normalized version, this strategy will be backwards compatible.

From our development roadmap, at this time there simply is zero interest amongst paying customers (or 98% of free users), so we can't justify the cost of building, documenting, and supporting this, given that we have a lot of other feature requests. However we'd certainly welcome help from the community in making ProGet Windows container ready; please let us know if you'd like to help!!

Because this error is coming from MSBuild (a third-party tool not written/supported by Inedo), your best bet will be to search for that error code, and follow those instructions. Google Search: MSB3884

I managed to get sql to install by manually creating the database, strangely enough the otter installer wouldent even install sql express, anyways once i got past that it wouldent give me the option to install it on iis even though the prerequisites were met so I installed the build in one but keep getting connection refused any ideas, all firewalls are off, and the otter web server is running which had to be manually started.

See the Configuration File documentation for more information.

Another option to consider is just defaulting to the BuildMaster Server time zone. At least for us that is the same as the Jenkins system. So use that as a Default but allow a setting in the Artifact Deployer if someone needs to be different.

If you are using a newer version of MSBuild, see: http://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html If you are stuck with an older version, the solution is specific to whatever CI server you're using, e.g. with BuildMaster you would use the NuGet::Install-Packages operation; with TeamCity you would use the NuGet Installer build runner, and so on.

Looks like these symptoms are caused when the host goes OOM

Just pushed another version; let me know if that one has any other issues.

I have experienced what I suspect is the same problem. The package file works if downloaded manually via the website or if downloaded WITHOUT contentonly. If downloaded with contentonly=zip the package is empty. Installing the package via UPack results in an empty package as well. For me, this problem occurs when creating the Universal Package zip file using PowerShell's Create-Archive command. If I use 7-zip or UPack the problem does not occur. This is a bizarre problem and should be addressed as many sysadmins probably reach for PowerShell first. This kind of problem is near rage inducing :)

Sounds like the service is crashing because of connectivity problems with SQL Server; this is expected behavior, as the service cannot operate without a database and will crash if it can't be reestablished after a few tries. This is why it's not logged in BuildMaster's error logs (as those are stored in the database). You could see it in the Windows Event Log however. Short of fixing connectivity problems, you can just set service to auto-recover.

Pipeline variables are considered Configuration Variables, not Runtime Variables. When you use the Set Variable Value statement, you are creating a runtime variable in the current scope, or updating a runtime variable in the current or parent scope. If you want your scenario to work, you would need to do this... #create a runtime variable from $pipelinevar1, which will resolve to configuration variable set $pipelinevar1 = $pipelinevar1; # update runtime variable created in above scope { set $pipelinevar1 = somevalue; Log-Information value is as set here: $pipelinevar1; } #general { Log-Information value is as set in pipeline here: $pipelinevar1; }

If you want to quickly add something like this are familiar with C#/.NET you can already create a custom package store to do this, see: Extending ProGet Beyond that, we will consider this as a first-class feature as you suggested. If you have any specific thoughts as to what would need to be configured for the hooks please add them to this thread.

These days, the general workflow has really evolved to assembling artifacts into "packages" and then pushing to a package manager; basically Build > Package > Deploy I think the reason is that it's much easier to deploy known packages (then assemble them from artifacts). In this case, ProGet serves as the Package manager step.

Hi Alana This page (https://inedo.com/support/documentation/proget/core-concepts/connectors) has no info that I have to link the connector to my feed. Just add a little section at the end with a screenshot so the users sees what he has to do after creating the connector.

Thanks for the quick reply! Ok, that's a shame but understood.

Unfortunately it's a bug in IIS/COM API Library. There is no resolution, it "just happens" sometimes. On some servers, especially older ones, it seems to happen more frequently. Rebooting tends to fix more persistent ones. if it's an issue, then just put in a retry loop with a timeout.