inedo-engineer

Hi @brandon_owensby_2976 ,

The image that's being used is mcr.microsoft.com/dotnet/sdk:6.0, which is technically a "fat manifest" that points to a number of platform-specific images. But that's all handled by the Docker engine.

So if you're getting a Windows-based image, then it means the Docker engine is not using Windows. I haven't used DockerDesktop in years, since WSL2 is much more reliable and a similar-to-production experience.

I mentioned this in my other reply, but I would suggest to "play around" with the commands using docker run ... to see if you can get this working using that container.

Once you can get it working from the CLI, then it won't be problem for Buildmaster to do the same thing.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You can run Linux VMs on your laptop without an issue. They don't require much disk space or memory, and that's what WSL2 does behind the scenes.

Docker containers aren't designed as or intended to be "servers" per se; they are meant to just run a single program without worrying about any operating-system dependencies. You can technically SSH into them and run other programs, but that's really only done in specialized debugging scenarios.

In other words, you should not be "running commands" inside a Docker container, whether using SSH another means. Instead, you use the docker run command, which will create a container from an image, execute a command, and then stop the container.

As far as getting unit tests to work, that may require additional dependencies. I don't really know. But they way to test that is by running commands like this:

docker run --rm -v "$PWD:/src" -w /src mcr.microsoft.com/dotnet/sdk:10.0 dotnet test

That basically just spins up a container to run dotnet test. That is what BuildMaster is doing behind the scenes.

When you do docker run proget.inedo.com/productimages/inedo/buildmaster:2026.0 it's doing exactly the same thing, you just don't get to choose get to choose the command that runs when the container "spins up".

Hope that helps

Thanks,
Steve

Hi @brandon_owensby_2976 ,

This isn't really something that makes sense in the Docker paradigm. Keep in mind that a Docker container is essentially a wrapper for a single executable and is designed to be disposed after the command runs. That's how the Image-based services work as well.

If you want to get Linux builds working, I'd start with a Linux-based server (create a VM) and SSH into it. You later try out Image-based services as well, but that also requires a Linux-based host.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

Based on the error message, it looks like you've got Docker Desktop configured to use Windows-based containers, not Linux. I'm not sure if this can work on Docker Desktop; it's just a not a stack anyone considers/supports for use cases like this.

The underlying error appears to becoming from the dotnet tooling. Though it's hard to say without troubleshooting further. Basically, something in the stack is calling the Linux tool id , which isn't going to work on a Windows container.

If you're evaluating/testing, I would just use a virtual machine and pretend it's a remote server or something to that effect.

Thanks,
Steve

Thanks for sharing all the details @sgardj_2482.

You shouldn't need to modify the Embedded Database like this when using a GMSA. It should continue to work just fine using a username/password as configured. If you ran into an issue when changing the service account, please let us know.

Note that we don't support modifying the Embedded Database like this, so please be aware this may suddenly break in a future upgrade.

Hi @certificatemanager_4002 ,

This is really easy to do in ProGet and no need for a "scan". I can't even imagine how such a "scan" could work.

Anyway, you just simply need to add a connector filter that prefixes your internal packages. For example, our filter for NuGet packages would look like Inedo* - which prevents any package named that coming through a connector.

Check out this article to get some more details:
https://blog.inedo.com/software-supply-chain-security/three-things

Thanks,
Steve

Hi @daniel-mccoy_4395 ,

About the only way I can imagine that happening is if you delete the version from the feed and navigate to that page. Or, if it was a remote package, and somehow the connector stopped working between pages.

I would try to find a pattern and see if you can reproduce this more consistently.

Thanks,
Steve

Hi @Ashley,

I took a look into this error, and the constraint that is failing only checks for the Project_Name to not be an empty string. Based on your pgutil command, I'm guessing $ProjectName is set to null or an empty string. Can you verify that $ProjectName is not null, empty, or whitespace?

Thanks,
Dan

Hi @daniel-mccoy_4395,

Based on what you've described, it sounds like ProGet is indeed blocking downloads; this is visible in the ProGet Web UI with a "Download Blocked" indicator. If you try accessing the download URL, you will in fact get a 400 error.

However, NuGet/Visual Studio aggressively cache package - which means they aren't even attempting to download them. If you clear all the NuGet caches (system, user, http, project, etc), then it should attempt to download then again.

That said, as of ProGet 2026, we no longer recommend downloads. This is one reason, but there are more reasons.

Here's an work-in-progress article that discusses our new guidance:
https://guides.inedo.com/vulnerability-management/containment/

Cheers,
Alana

Hi @carl-westman_8110 ,

Not really... Feeds and Views are a bit different concept and we don't really encourage using the presence in a particular feed as a means to identify whether something has been released. Instead, we'd encourage using Pre-Release Packages & Repackaging
, which make it obvious from simply lookin at the version (i.e. 1.1.1-rc.7 indicates not yet released).

Thanks,
Alana