Hi PhilippeC;

Not sure I totally understand; can you give an OtterScript example, and then sort of describe how the behavior Should work?

Yes; you would use a Docker feed and a Connector for this. ProGet will cache the container images and metadata, so it should give you better reliability when Azure container services has an outage or they introduce a new "feature" that breaks things ;)

Get in touch direct,happy to work toether on POC/implementation

We're targeting Q1 for this feature, to integrate w/ on-prem container vulnerability scanning.

Working w/ long paths is tough, and requires specialized Win32 API calls. Maybe we missed one, maybe NuGet or VS missed one.

Is this an error on the ProGet server? I.e. does its how up in Admin > DIagnostic Center? Can you pull this package to ProGet service, and download it from WebUI?

We haven't heard any other complaints, so it leads me to think it's either your end (proxy?) or npm's end (blocking). We have no idea what their blocking mechanism could look like. For all we know, they could be doing agent-string filtering, and blocking requests from ProGet software, but not your web browser or npm client.

Best bet is to run ProGet through a proxy (like fiddler or wireshark), by going to Admin > Proxy. Then you can see exact traffic.

Of course, plan versioning is introduced in a later version, and Rafts (which allow for Git-based storage) is coming in 6.2.

I definitely understand the hesitance to upgrade, but worth noting ---- for once 6.2 comes around we'll offer some great migration tactics to let you pull applications from really old versions of BuildMaster. We'll also better support multi-instances of BuildMaster, so each group can upgrade as they'd like.

That said, the Plans database table will contain your OtterScript plans. Not sure if that's a good solution, but pulling from that table will give you latest versions.

ProGet does not support SQL Server 2005; sometimes the installer doesn't detect it, but this error will happen if you're using SQL 2005.

There are no additional logs; newer versions of ProGet may improve, but ultimately if this is a result of rate limiting there wouldn't be much to detect. I think the registry file it's downloading is massive (hundred of megs, gigabyte?), so if it was rate limited there'd be no way to detect it.

You could run PRoGet through a proxy (like fiddler or wireshark), by going to Admin > Proxy. That might be your best bet to see exact traffic.

Not sure which organization you're with, but you may have been blocked by npm. They recently announced they will be blocking large organizations; I'm not sure how to check this, because the only information is that blog article.... but it sounds like rate limiting to me?

I don't think it's a SQL problem, but from your screenshot it looks like you're using SQL 2005. You should definitely upgrade that. ProGet (or Microsoft) doesn't support that anymore, and hasn't for a couple years.

Hello;

There may have been a miscommunication somewhere; do you know specifically what you were told?

We recently added the Feeds Management API, but that's only to manage feeds (not packages).

I just updated the documentation, and it will be published soon.

You can delete (permanently remove) or unlist (hide from most search results) NuGet packages from your feed by navigating to the package page and clicking the corresponding Delete Package or Unlist Package button. These actions require the Feeds_DeletePackage or Feeds_UnlistPackage permission attribute, respectively.

To programmatically delete a package from your feed, you can use the NuGet CLI's delete command, or make a DELETE request via HTTP:

DELETE http://{proget-server}/nuget/{feed-name}/package/{ID}/{VERSION}`

Note that this behavior is different than NuGet.org's DELETE command, which unlists packages instead.

To programmatically unlist (or relist) a package, you can use the NuGetPackagesV2_SetListed method within the Native API.

Is that helpful?

The ExecutionDispatcher doesn't start right away after a service restart; it takes about 5 minutes after service start. This is a known issue (it's a hack/workaround), that we will fix ASAP; it has to do with the fact that we don't want to run an execution while the agents are updating.

InedoCore 1.5.1 should not have been available to be downloaded (we recently moved the inedo.com/den/feed to proget.inedo.com/upack/extensions). It's deleted from the feed.

You should be able to delete it, then reinstall 1.5.0 as per normal.

ProGet does not support the deprecate command, but you could accomplish the same thing by adding a Manual Vulnerability.

We can't seem to figure out what the deprecate command actually does, or how it's supposed to work. It's pretty poorly documented, and since there is no deprecated flag in npm package metadata, the client must be doing some strange things to check. Who knows...

Anyways, I'd stick with Manual Vulnerability, since at least that's documented a lot better and won't change from client version to client version.

The Execution Dispatcher (Admin > Manage Service) doesn't start immediately after service restart; this causes the same symptoms you're seeing now. You can manually trigger it on that page, or just wait.

It's a known issue, and just a (temporary) workaround to problem where executions start in the middle of agent upgrades. We've addressed it in Otter, but it's a bit complex to do in BuildMaster pre-6.2.

The homepage will attempt to connect to inedo.com to download latest news, and it will also connect to the database to provide a summary of feeds (dashboard). However, if either of those operations times out, then you should get a prompt error.

Maybe, for some reason, the request isn't even being routed to ProGet. You can connect ProGet to a proxy like Fiddler (Admin > Proxy), and then attach to SQL Server to see if anything is timing out..

All "names" are, unfortunately, limited to 50 characters; we thought this was "more than enough", and it's a common limitation in a lot of programming languages.

This is not something feasible to change for a lot of reasons (consistency across all products, database columns, UI validation, etc)...

Assuming that ProGet has access to inedo.com, ProGet will automatically activate. Otherwise, you will have to manually activate. Activation is required when the CPUID changes or the MAC address changes. So, the easiest thing to do is just to ensure those don't change; these are almost certainly options in the VM Host.

It's possible to programmatically active, but quite bothersome. You'd need to call our (undocumented) product registration endpoint, then add data to the ProGet database, then reset the web application. We don't really support this, and it's quite fragile (i.e. having someone else maintain this as a SOP), so it's best to just ensure the ProGet VM doesn't change and require re-activation.

Hi Chris,

You'll need to run the NuGetPackagesV2_SetListed method instead. In order to this, you'll need to mark it as non-internal; this can be done with a simple database query...

UPDATE [__StoredProcInfo] SET [Internal_Indicator] = 'N' WHERE [StoredProc_Name] = 'NuGetPackagesV2_SetListed'

This will be also be updated in 5.2.10 as PG-1549.

Here's the response that @jrasch posted to that ticket;

The All Versions tab should definitely still be there, and the only case I could see where it's hidden is for the feed type of "Docker" which does not use versions.

Can you try:

• Hard browser refresh e.g. CTRL + F5
• Verify that you are logged in and not browsing anonymously

Is that what you're looking for?

Basically it sounds like it was an issue of either not being logged in, or some old Javascript cached in your browser? It's hard to say, because you had responded in the ticket that it was resolved...

We recently moved our documentation; do you know where you found those 404s? We're also monitoring via Analytics Tools as well, but finding sooner is better :)

Anyways PSCall is good in Orchestration Plans (can be done in a Configuration Plan, under some conditions), and PSEnsure is best for Configuration Plans.

Explaining Ensure vs Execute can be tricky, but I'd recommend checking out our ebook, called Windows-first Guide to Infrastructure as Code and Continuous Configuration Automation :)