Hi Alana, Thanks for the information. I've reinstalled ProGet and IIS several times and at attempt four it suddenly worked fine. So I'm not touching the setup anymore and will keep it as-is now! Thanks, Eelko

ProGet does not push packages; but you can use a tool like BuildMaster to help build a pipeline for your own nuget packages, and push to different nuget servers along the way.

Hi Upgrade Path : Serveur Run the Hub installer on your Otter server -> https://s3.amazonaws.com/cdn.inedo.com/downloads/desktophub/OtterInstaller.exe Extensions (In Admin Menu) /!\ Git Extension shows 1.0.3 after its upgrade while it is expected 1.0.4. but it is working fine Agents. Do not update agent using Otter (Upgrade Agent). I had some trouble with this option. I'd rather upgrade using my software deploiement tools - (Remove old agent, cleanup folder, install new agent) Best Regards Philippe

Proget non hub installer on French W2016 Core server with remote SQL db is working fine The pb exist with BuildMaster Hedgehog but not with Otter Best regards Philippe

These will be included in the next maintenance release as per this issue: PG-1406

Soon --- this is a known issue, but we are in the process of resolving it; please see InedoCore#96

Of course, modifying a package file (i.e. stripping symbols/source) will cause the hash code to change, which is what the integrity check uses. There's no way around that. The stripping feature is important, because Visual Studio will not use a symbol or source server if the package has embedded symbols in it. You aren't supposed to put these in a nuget.org package, but some people clearly do (as the example above). So, just pick which is more important to you.

Update: I've filed this bug with Docker: https://github.com/docker/distribution/issues/2649

Hello, these errors are quite erare, but it can happen in dealing with randomly disconnecting web clients. The easiest thing to do is to set automatic recovery on the service. You can do this on the "Recovery" tab. You could also upgrade to iIS, which mas more transparent crash recovery.

hi Markus, you should be able to put credentials in your Connector. Then you should be able to connect.

Hello Charles, upack pack expects a directory, not an individual file, so the command should be: upack pack C:\location_of_upack_json_file C:\directory_containing_my_setup_exe --targetDirectory=C:\mytargetDir\build_artifacts

I figured that by remove Windows Auth and going back to build-in security but that won't work for my scenario. I've moved to an azure registry and it's working fine. I'm sorry I can't use Proget for all my feeds though. Cheers, ET

Hello Jim, You can run the ProGet service in interactive mode to see its logs: Stop the ProGet service. In Command Prompt or PowerShell, run .\ProGet.Service.exe run from C:\Program Files\ProGet\Service (or wherever you installed ProGet if you didn't use the default location). It will run the drop path monitor every 60 seconds by default. The message for the drop path monitor starting is Executing DropPathMonitorExecuter.... You can edit Service.DropPathMonitorExecuterThrottle in /administration/advanced-settings to less than 60 seconds if waiting gets too annoying. Immediately after the drop path monitor runs, there should be a message that says Scanning for packages in f:\dsc\droppath. This will be followed by Found f:\dsc\droppath\file.ext any packages it finds. In order to be found, the package files must end in the expected extension: .tgz for npm feeds .nupkg for NuGet feeds .gem for Ruby Gems feeds .upack for Universal feeds .vsix for VSIX feeds If an error occurs while trying to add a package from the drop path, it will appear on a line shortly after the Found f:\dsc\droppath\file.ext line, starting with Error installing package:.

i'm afraid we won't be able to help with that; please consult with the BizTalk ESB team or forums.

If you upgrade to the latest v5.6 (currently 5.6.11), then it should work OK!

An "Access to the path is denied" message is coming from Windows. Permissions aside, a likely culprit is anotherr process (anti virus, backup, etc) is locking the file and preventing access. Sometimes you'll need to use ProcMon to identify what this is. ProGet does not requests locks when reading files.

You can Log-Information to see what $WorkingDirectory is. Unless you set a value, it will be something like C:\BuildMaster\_SVCTMP\_Ennn\D0 where nnn is internal identifier of the execution. Log-Information Working-Directory is $WorkingDirectory;

I would suggest to use the "Run MSBuild Script" Action instead. Then you can specify any of the properties.

Hi, OK, thanks. Just to let you know, this was from version 5.10 to 5.11. David