Hi @arozanski_1087, Thanks for following up with us. I'm glad you got this working! Please don't hesitate to reach out if you have any other questions for us. Thanks, Rich

@vadim-k_6062 good to know that fixed it! We will add a message to the InedoHub then to help users if they come up with this -- https://inedo.myjetbrains.com/youtrack/issue/DH-42

Hi @antony-booth_1029, Starting in version 6.2.21, we actually made a new variable function to create the URL for you. You can use the $BuildMasterUrl(build) function and that will generate the URL. If you are running that from within the context of a build, you will not need to specify any other parmaters. You can see more about its usage in the functions reference in BuildMaster by navigating to Administration -> Reference Documentation section -> Functions. We have also added a $BuildMasterId function if you need to get the BuildId directly. Hope this helps! Thanks, Rich

Hi @sbolisetty_3792, What version of BuildMaster are you running? It looks like the third-party Slack extension was built using the legacy SDK and extension model, which will not work in BuildMaster 6.2. We recently added documentation on how to POST to Micorosft Team's Webhook connectors. You could very easily adapt this to Slack by creating a new WebHook in Slack and posting to the Slack WebHook URL instead of the Teams Web Hook URL and tweaking the message text you are POSTing. Here would be an example Slack JSON to POST: {"text": "**BuildMaster - New Build** $ApplicationName $ReleaseNumber.$BuildNumber has completed. View it at [Build $BuildNumber]($BuildMasterUrl(release))."} Note: $BuildMasterUrl() is only available in 6.2.21+ Hope this helps! Thanks, Rich

Hi @viceice, I did a few searches and have you tried setting the hostsProxyHeaders> Maybe something like this: traefik.frontend.headers.hostsProxyHeaders=www-authenticate? The docs make it sound like it will look in those headers for URLs that are proxied. You could give that a shot. Thanks, Rich

Hi @bju_2095, Are you using a Nuget.config file for specifying your multiple feeds? From what I can see is Azure DevOps wants you to use the NuGet.config when specifying multiple NuGet feeds. I would lean towards this being an issue with Azure DevOps. Can I confirm that you are using ProGet 3.2? You could create a new feed in ProGet with connectors pointing to the existing two feeds you need. Then Azure DevOps would only need to connect to one feed. Thanks, Rich

Hi @harald-somnes-hanssen_2204, The fix is scheduled for release in ProGet 5.3.16 which is due out on Friday. I'll reply back if anything changes. Thanks, Rich

Hi @arozanski_1087, Technically they do not need to run as the same account, but it does simplify things. Especially since they share the configuration file that contains the connection string. Also, please make sure that your IIS has the correct features installed. You can see the Configuring IIS Roles & Features for Inedo Products documentation for that information. Were you using that exact service account previously on the integrated web server install? If you were there shouldn't be any iossue connecting from IIS then. Thanks, Rich

@viceice Good catch! @csyy321_2677 Could you update your port as @viceice has described and let me know if that works? Thanks, Rich

If there is a guide somewhere, how to traverse and push, then sure. But I haven’t found such a thing. The only thing I’ve heard from other forums is a question: Is ProGet really a good option for Maven? As with you, I don’t have much knowledge about maven. Working on it though, but as you’ve mentioned, it’s just weird. However, I’ve got a hunch it’s sort of like a file repository. Where everything connected to a version is put into a folder and pom. Unlike nuget where a package contains a version and lists of dependencies in the nuspec file. I don’t really know, but that’s my impression of maven vs nuget. I’d suggest you guys should invest time in the types of products your customer might come from. Don’t underestimate the power of a guide, easy transitions and quality checks to reassure customers. Look at Octopus Deploy how much effort they do, I rarely have issues figuring out how to do stuff with their features. By the way, I appreciate that ProGet Free has enough features to let me do a POC. Only Nexus Sonar is at the same level as ProGet free when it comes to the amount of repository support.

Hello; That was a mistake/typo in the docs, which i've since corrected; https://github.com/Inedo/inedo-docs/commit/cd7091e8eaf37939949d0681f137a78d579acbc6 The correct url is https://«proget-server»/«feed-name»/«packageName»/«versionNumber[optional]» But note, that's only for NuGet package. You can easily find the download url for any package from the UI, by looking at the Download button on the package page. Cheers, Alana

Found this https://inedo.com/support/kb/1758/automatic-license-activation-not-working#workaround

Hi @aneequaye_1868, I apologize, I was speaking from the mapped folder on the Docker host. Inside the container, it is still /var/proget/packages. Does this still happen on the latest version of ProGet? We did make some changes to how the headers are returned in the latest version, especially for feeds that require authentication. Thanks, Rich

Hello, please review License Key Activation Docs, especially the note at top talking about Automatic License Activation Not Working in older versions. Also... please upgrade. ProGet 5.3 is great!!

Hi @atillio-menegoni_1334, If you navigate to that artifact version in the UI and verify that cdd-application-5.7.0.5.zip exists in the list of files? If it does, can you click the file and see if it downloads manually for you? Thanks, Rich

This isn't currently supported, but something we can consider adding if you're open to using our Feature Request Process. One thing that would go a long way in helping us understand the usecase (and way to explain it to users) is suggesting where precisely we should document this, and how. https://docs.inedo.com/docs/proget/reference/api/asset-directories-api (source)

Thank you. this situation seems to be sorted in 5.3.15.

Hi @srbauti_9412, The best solution to this would be to create a new NuGet feed that uses a self-connector to connect back to your existing NuGet feeds. You can then use the connector filters to handle filtering by your package name format. Thanks, Rich

Hi @rhessinger, thank you for your quick answer. Works fine for me! Thanks and best regards, Philipp

Hi @toni-wenzel_6045, Currently, the only way to set the description would be to do it using the UI or the Native API. In order to set it using the Native API, you would need to do the following: First, Get the Docker Repository ID by making a GET request to <Base URL>/api/json/DockerImages_GetRepositoryByName?key=<API Key>&Feed_Id=<Feed_ID>&Repository_Name=<Repository Name> This will return a list of images (should only be 1 in the list) and you will need to get the DockerRepository_Id from each item. Then, you will need to POST a JSON object to <Base URL>/api/json/DockerImages_CreateOrUpdateRepository. The JSON object you would post would be: { "API_Key" : "<API Key>", "Feed_Id": "<Feed Id>", "DockerRepository_Id": "<ID from previous request>", "Repository_Name": "<Repository Name>", "RepositoryIcon_Url": "<Icon_URL>", "ShortDescription_Text": "<Short Description>", "FullDescription_Text": "<Full description (Readme.md)>" } Please note that you will need to populate all of the values. For example, if you do not populate the RepositoryIcon_Url, the value will be cleared. Thanks, Rich