ProGet already supports SemVer2 for Universal Packages. Unfortunately, NuGet does not yet support this. Remember they also have a "quasi-support" for this quirky 4-party version number as well, which so many packages utilize. Please refer to the NuGet Team's documentation on SemVer. 3.0.0 and up support SemVer 2.0.0 with a limited capacity. Local folders and shares are unable to parse versions with multiple release labels or metadata due to the use of NuGet.Core.dll from the older 2.11.0 client. Project.json restore supports SemVer 2.0.0 and is able to read local folders correctly since it does not depend on NuGet.Core.dll. In some scenarios metadata is written to the disk folder path which causes. Multiple release labels are supported. Starting in NuGet Client 3.5.0-rc1 has added SemVer 2.0.0 for supported for local folders and UNC shares. It's a much more complicated issue than it appears at first, and with the velocity of the NuGet team's releases has slowed, and it's likely NuGet will not fully support this in a while (document was from Oct 2016). We may add some support for this down the line, but it would require a major change to the way we do package indexing, and thus could impact a lot of our enterprise customers. You ought to consider changing your requirement if you're going to use NuGet packages, given the limited supported from the NuGet team for it.

Hi Megha, Ensure application dont have selection of appPool right now, may be you can try create a powershell like below might solve your problem for time being. param( [parameter(mandatory=$true)] $iisAppPoolName, [parameter(mandatory=$true)] $iisAppName ) Import-Module WebAdministration #gets the iis application name $iisApp = get-item 'IIS:\Sites\Default Web Site' if((Test-Path ("IIS:\AppPools" + $iisAppPoolName)) -and (Test-Path ("IIS:\Sites\Default Web Site" + $iisAppName))) { #set the app pool to the application #Set-ItemProperty IIS:\Sites'Default Web Site'$iisAppName -Name applicationpool -Value $iisAppPoolName Set-ItemProperty -path IIS:\Sites'Default Web Site'$iisAppName -name applicationPool -value $iisAppPoolName -Force Write-Host $iisAppPoolName“ configured to web site: “$iisAppName } else { Write-Host "The App Pool/site does not exists" -ForegroundColor Yellow Write-Error "Failed to add application to the app pool" exit } Thanks, Srinivas

Thanks, that fixed it.

Thanks all, it seems the problem with the extension. One thing I've observed is the extension is not working for 5.6.5. As we end up in upgrading the buildmaster to 5.6.11 then it started working.

Thanks Alana, [EDO-2856] has been raised. Thanks, Clint

That type of difference is understood. Someone here asked me about it so I just wanted to clarify what should be expected as it was not clearly defined in the documentation as to what differences it would be reporting. Thanks.

There wasn't another role doing remediation. This particular instance was just supposed to be a simple check for a file just for display. I have orchestration plans that run and actually build servers. Other points of interest however: Why does running the configuration job for role Rebuild then return result for all servers, but the recurring job does not? I saw the same results with a more complete role configuration using the OtterScript "Ensure File" that would create the file as needed with remediation.

If you have Windows Integrated Authentication enabled, then it will not be possible to do this. The 401 is occurring before the request even makes it to ProGet, which is how WIA is designed. You can also set up a second site in IIS without WIA enabled. That would lalow the request to get to ProGet, and if you have an "Anonymous" pseudo-user configured with permissions, then the lack of a credential will be ignored.

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 :)