Posts made by apxltd

Thanks @sylvain-martel_3976 ! That's really helpful to know.

From a positioning standpoint, I think that WinGet is trying to replace the Windows Store while offering a more developer-friendly experience to create your own apps on Windows. But it's hard to say -- it's only 1.0 as you said, and the positioning has changed a few times already.

Our plan is to use Winget to deploy apps on servers using ansible playbook.

Can you tell us more about this? Lots of questions, hope you don't mind us trying to understand a bit more...

What apps? As in, applications your company created (first-party apps), or third-party ones (like Firefox or SQL Server, etc).

Where to host contents? WinGet doesn't seem to host the installers or package contents, so where will you host these files? Will you keep them on the internet (third-party apps), or have your own custom source (like a CDN or ProGet Asset Directory)

[First-party / custom apps] Do you already make installers for your apps? If not, how will you automate installation?

[First-party / custom apps], Have you explored ProGet's Universal Packages instead? I think these would be better/easier, especially for server applications. We've seen a lot of people use these over Chocolatey.

[Third-party apps] Why use a private feed? Is it for security/vulnerability? Quality checking? Etc.

@atripp @philippe-camelio_3885 whoops!

This error should be fixed already, and I just published 1.10.2 - please try that!

Thanks Simon! Much appreciated.

This will officially be our first "v6 preview feature" --- figuring out the general direction of v6 has been on my list, so thanks for helping out on that ;D

I can't imagine it will change between now and v6, but this allows us to work on documentation, etc. in the meantime. No ETA yet (I'll let the team take it from here as PG-1945), but probably in near upcoming maintence releases.

@scroak_6473 ah yes for sure -- actually it really could only be a user-level function with this proposal. Basically, this is just a page that allows non-admins to manage a subset of API keys (i.e. ones with only "Feed API" and with their name in the impersonate field) -- we proposing to change how API work, etc.

Let's make sure to definitely clarify this in the UI & documentation. I think you have a lot more experience working with "regular" ProGet users (i.e. non-admins) than we do, so I'm hoping you give some advice on how to best communicate how this all works to regular users, as to means to reduce the administrative work you do.

User Drop Down (from your screenshot)

• Add "Personal API Keys" link above "Change Password"
• Show link only to Authenticated users (i.e. Anonymous can't see it)
• Link navigates to /my/api-keys

View Package Page

• should we also link to Personal API Keys? Where to mention this?

Personal API Keys (new page)

• Show InfoBox based on user type (see below)
• Show table with three columns: Api Key, Description, and delete button ()
• Clicking on API Key opens a modal that allows editing the description
• "Create API Key" Button works as above (only description allowed)

Messages For Admins
This page shows only API keys with "Feed API" permissions that impersonate your username ({username}), and is intended for non-administrators to manage their own API keys. Because you have Admin_ConfigureProGet permission, you can [manage all API Keys in ProGet].

Messages For Non-Admins
Something about <user>:<password>? This page allows you to manage API Keys that ...?

cc/ @harald-somnes-hanssen_2204 I remember you had some other "regular user" suggestions as well (but unfortunately they didn't make the 5.3 release)

Hey @philippe-camelio_3885 ,

Ah, looks like this is a bug in the Scripting extension, and will happen if you don't specify the .AHCURRENTVALUE comment block.

I just patched it real quick (please install Scripting v1.10.2-CI.1), and now at a absolute minimum this would work:

<# 
.DESCRIPTION
Create AD Group 

.AHEXECMODE
$ExecMode
#>

Given your script, here are the other values I recommend...

.AHCONFIGTYPE
ADGroup
.AHCONFIGKEY
$Name

There's something a little funny about the collected Value after remediating drift, but taht's something we'll look at later. For now we need to get these docs published; they're draft for now.

Anyway please give this a shot and let us know how it goes

@Stephen-Schaff

Very glad to hear! It makes absolutely no sense makes that Managed Pipeline Mode would have any impact on how these libraries behave... but there you have it. These libraries are ancient, and even Microsoft has no idea how they work anymore.

Apparently Microsoft is working on shipping brand new libraries (no COM interop magic) in .NET6, which means by .NET8 they just might be usable, and then perhaps in another decade they won't require mysterious changes

@Stephen-Schaff FYI; looks like this got added as a result of your feedback. Easy change, mostly to prevent the "locked out" symptom when switching.

Let us know what you find out about test system, etc.

Thanks @Stephen-Schaff, we will definitely figure out how to get this working.

The /debug/integrated-auth is just a URL you can type in, like https://<yourinstance /debug/integrated-auth. It provides some details about the current configuration, like this:

https://proget.inedo.com/debug/integrated-auth

However, it will only help us identify potential problems once you've changed the configuration.

--

Since downtime is a concern, let's start by getting a testing environment. Can you install ProGet on a similar server, and then just use the Trial license key? You can request one at my.inedo.com.

If this is a "permanent server" where you wanted a testing/training place for all the various functionality, we would ask for a license... but this usage is fine, most especially given all the headaches.

Once you have that, testing should be a lot easier.

If we can reproduce the problem on the test server, then that's good news - because we can try some basic config changes.

The first thing that comes to mind is set LoadUserProfile=true on IIS AppPool. That "works wonders" due to the bizarre behaviors of some of Microsoft's libraries. The second is trying a different username. We can just keep going, all the way down to running the webserver outside of IIS.

We can also just keep iterating on code, finding places to add new debug information, etc.

At this point, even if you could test before switching, it wouldn't help... because it would still not work. Making it easier to switch without needing to reset password, is a problem for a different day... for now we need to figure out how to add diagnostic information.

If it's as simple as LoadUserProfile=true, then and lesson learned -- I guess we'll try to detect and warn, or atleast be trained on support to know how to respond.

And if we can't reproduce the problem on test, then we'll just keep coming up with ways to figure it out quickly while minimizing downtime. For example, if we absolutely had to, we could get a second ProGet instance on one server, just to try this out, and not impact the first.

Anyways from here --- let's see what we can do on the test server!

@Stephen-Schaff I'm sorry that you're having configuration challenges; active directory is very complicated, especially on old servers, complex domains, etc.

Another thing to try is visiting /debug/integrated-auth in your instance, but that only uses the current directory provider (so you need to switch first), and it may not provide any new information.

I tried using your Active Directory debug tool and it the settings work perfectly there. The same settings fail in ProGet.

The software/code is identical, so if this is happening then it means something is different in your production environment. The most likely case is that the user account running ProGet has different permissions or is otherwise unable to query the directory in the same way. You could also try setting LoadUserProfile=true, that seems to help with Microsoft's libraries for unknown reasons.

We are happy to add product enhancements to make this easier to debug, and identify what's wrong. At this point, it's a big guessing game as to what's different about your environment, because it works for everyone else.

As much as I really like ProGet (both price and features), I am going to have to spend some time today to go shopping for a product that can integrate with my Active Directory system. :(

I can probably convince my Operations Team to give it one more go if you have any suggestions.

We're doing our best to help you and try to solve this bizarre and complicated problem that only seems to impact you. I know you're frustrated, and we are too, because we don't like seeing our software not work in some environments. We could just as easily blame you or whoever configured your environment, or perhaps Microsoft, who wrote the buggy libraries we use.

But you're a smart guy, and you must know that this abrasive communication style causes only unnecessary stress to the people you interact with. You are certainly intelligent to know it's not appropriate or productive, either.

So, please be more considerate. Or if this is your preferred vendor management approach and communication style, then do "go shopping" and do find another vendor.

@Stephen-Schaff said in Feature Request: Limit Container Images to those that are inherited from another feed:

It is possible that you are underestimating the value that enterprises place on governance of their processes.

It's really valuable, but from a marketing/sales perspective, it's hard to "compete" with the likes of ServiceNow for governance improvement. Containers are already too much in the weeds for the folks with governance problems/pain points... and they can "just throw a guy they trust to manage the details, like Stephen"

@Stephen-Schaff said in Feature Request: Limit Container Images to those that are inherited from another feed:

Multistage Dockerfiles to not pass any part of the Dockerfile that was used from a previous stage on to the later stages (aside from any files copied).

That makes sense, but you could still validate that containers "inherit" from a known base image. In ProGet, you can navigate across base images.

@Stephen-Schaff thanks again for all the thoughts. This is making a lot of sense.

To summarize the Multistage-approach, "each build is done in its own sandbox so that the tools used to build the software are kept in lock-step with the software", or something like that.

Anyways, I really dig it, and I like where your thoughts are on this! This is the sort of "engineering/process rigor" I always envisioned to help companies build with our tools.

Actually, I'm already thinking of how we can do all of this with not just ProGet (probably using a function I spec'd out ages ago... happy to share that idea with you at some point, it'd totally work I think), but also integrate some great self-service workflows into BuildMaster for this sort of thing.

Now all that said.... I'm an engineer by trade and by training, and maybe ten years ago I would jump on this idea, and code it all myself over a weekend

My company starts to balk after you get over a few thousand dollars unless the value is really big.

As well they should! I do the same

The reason I ask the "how much more would you pay" question is to get a "gut feeling" for demonstrating/articulating value. It sounds like this gap is pretty big right now, and that's something I'd like to work on.

This is more a marketing exercise, and not something I'd normally do in a venue like this, but the next InedoCon is a ways off, and you seem to have a great grasp on these topics already!

Now just to be clear, we don't intend on price hikes, especially for a feature like this, but one of our biggest challenges (thanks to an engineering CEO ) is demonstrating value to buyers.

So working on this, some quick back-of-the-napkin math shows that "30% of $2k/year" is $600, or at most 6 developer hours of internal value (whether that means saved or gained). That's not very valuable.

What I'd like to demonstrate is the business case for why this feature is easily worth $10,000/year (and probably even $100k/year) to companies with 50-100+ developers. That would be very valuable.

This is a really difficult exercise...

It's actually pretty easy easy to do demonstrate this kind of value with the high-availability feature alone. When 100 developers lose an hour of productivity due to a failure of ProGet, that's $10,000 lost. If your ProGet Basic instance goes caput, you'll lose a LOT more than that.

Of course, the problem with the high-availability feature, however, is the skills and mindset required to monitor/maintain high-availability things. If you don't have the infrastructure team on call that knows how to monitor, how to respond, how to support developers, etc., then it's not a feature you can use.

The value of this feature idea isn't so clear, at least in terms of Time (delivering quicker, increasing productivity), Money (lowering labor costs, increasing profits), or Risk reduction.

But even if we figure those out, the major problem I see with this feature is the skill/complexity in using it.

With the high-availability feature, you need to have a high-availability organization, but a lot of organizations already have that, so it fits right in.

The knowledge/skills gaps seem much larger, and the Problems an organization would need to have are complex. A buyer might think, "So an 'unapproved container' made its way to production, despite passing all the acceptance tests... is it really a problem?"

Anyways just brainstorming! But this is just part of the process.

There's not, but how about doing a "manual sync" by just copy/pasting the infrastructure JSON? Then switch once you're ready?

Thanks @Stephen-Schaff

Great idea, I added a product change issue (PG-1906) that will block enabling windows auth within ProGet unless the user can be found. This should greatly reduce the problems.

@Stephen-Schaff thanks for taking a look!

In addition to container development patterns, I'm also researching the so-called software supply-chain attacks... and I think that the inherent complexity of Docker and containerized development expands the attack surface exponentially.

The first is that the Dockerfile is usually thought of as the source of truth for the container build. Any configuration that is setup in the auto build should look at the final container image layer in the Dockerfile (so you get the real one if it is a multistage file). It could allow the user to select from any history of that container image as the "base" image. But just selecting any base image could put the selection at odds with the Dockerfile.

Can I pick your brain a bit more on this? What do you mean "source of truth for the container build"?

Is this Dockerfile typically stored in source control, alongside the application source code? In a world of cookie-cutter microservices and microapps, it seems these Dockerfiles should be nothing more than the absolute basics on top of a base specific image?

Separately, but related... I just read up on multi-stage builds and the Builder pattern vs. Multi-stage builds in Docker, but I'm struggling to see how this all adds up to real-world use inside of organizations?

Is this really a pattern that is emerging? Giving development teams not only control over their own base image, but over the tools to compile/build their code?

This just seems to add another layer to what ought to be a very simple process, and more opportunities for supply-chain attacks.

BuildMaster seems to have a "we will build your Dockerfile for you" feature. Which is fine until you need some complicated stuff in the Dockerfile that is not supported as a feature.

Definitely something I want our content to address; I think the "build for you" is good for these cookie-cutter microservices/microapps, which seem to be a better way to go than pushing all the Docker complexity to development teams.

I think that when this becomes a "Must Have" for me, I will see if I can meet the need with a web hook.

Well you definitely get the value in it -- but convincing others the importance of this sort of features is a real challenge, and that's where the content I mentioned comes in.

Question: how much more would you pay (or encourage your organization to pay) for ProGet if this feature were to be there? 20% 100%? 1000%? Why is it worth that extra?

I ask because that's an important way for us to start thinking about "value", which is what the check-signers want... and ultimately how we need to think about which features and content to invest in developing.

Hi @Stephen-Schaff_8186 , thanks for the feature request!

I like it. This is a good idea, and sounds like a way for us to enforce the "base image" pattern on the ProGet-side that we want to promote with our products. This is how we do it on the BuildMaster-side: https://inedo.com/buildmaster/containerized-development-in-buildmaster

Would you mind taking a look at it, and sharing your opinion on the approach? This is a solution we developed from the "outside looking in", since we simply don't have firsthand experience with this problem.

We are focusing a lot of our efforts on "why to" content, as I call it. This is even more important than the "how to" approach (which, that above article demonstrates), because it speaks to a problem many folks won't even realize they have. "this is just the way docker is" is something I hear in the field, all the time. My take is -- if we don't have a lot of detailed "why to" content about the feature, then it may as well not exist.

To give you an idea of what I'm talking about, our team just finished writing a pretty comprehensive and easy-to-understand guide on .NET5 Migration; the articles are here -- https://blog.inedo.com/tag/net-5 (fill out the form on any of those posts to get a copy).

We've got some other guides in the pipeline, and I want to start on containerized development as well. So the more feedback from advanced folks in the field, like yourself, who think of these ideas, the better!

Cheers.

Hey @nicolas-morissette_6285,

Thanks for clarifying!

So it sounds like this is a non-critical integration point. In other words, you're not building a workflow that relies on the two to be integrally connected, it's more a "convenience" such that one team get another team's developer library packages more easily.

I'm more nervous about enabling / encouraging the first use case; given the velocity and unpredictability of ADO's changes, there's a high change it will "just break" some day -- and as you've seen from their support, it's hard to get "them" to care. We most definitely care, which is why I'm cautious about putting us in a position to be responsible for customers' infrastructure breaking on account of a third-party API suddenly changing.

We most definitely work with a lot of teams at Microsoft, but their internal org hasn't really changed in the many years since I first saw this...

... so a lot of times, it's partnering with customers to push different groups at Microsoft to work together to serve what should be their common interest (i.e. a paying customer). For example, getting AzureDevOps Packages and NuGet team to collaborate on API things.

After the change in guard at VSO/ADO(i.e. after Ed Blankenship), we really don't have any meaningful contacts or pull w/ that group. But we definitely have contacts and work closely with other teams (like NuGet team, etc).

All that said, we'll also work-around this quirk, and I've put in a change (PG-1862) to accommodate this. But just

Hi @nicolas-morissette_6285 ,

Can you help me understand the use case here of ProGet and Azure DevOps Packages? Basically I'm a bit hesitant to invest in continued work-arounds for bugs/quirks in ADO Packages.

The ADO Packages team has made it very clear they aren't interested in spec compliance (whether NuGet or otherwise), and that they won't support interoperability with any other tool aside from Azure DevOps. That makes sense because they want you to only and entirely use Azure DevOps.

We've already work around one quirk, and I have little confidence that fixing this quirk will actually solve the problem (i.e. enable the use case you're trying to build) and that it will stay fixed. In a few weeks/months, when they ship some new functionality, your hybrid-ADO Packages usecase may break again.

For example, when ADO-Packages decided to block "private upstream feeds" (I guess that's what it's called?), it disabled the use-case of having ADO-Packages pull from ProGet servers, or vendor's feeds, or anywhere other than NuGet.org or ADO-Packages feeds. Fortunately it's easy enough to work-around in ADO.

Bottom line, using ADO Packages this way may prove to be very fragile, and you may be better served by not using ADO Packages altogether. A lot of other users have made that decision, and ADO works fine (better IMO) without using their Packages feature... and it's highly likely it will continue to indefinitely.

Alex

Hard to say, but there were some bugs with NuGet.org, where some packages would not show up when queried through the v2 API, but would come with v3. I wonder if it's related to you using a v3 API connector, but a v2 API call to ProGet? It should work.

You can append #v2 to a nuget.org connector's API to force it to use the v2 api instead of the v3.

There's no limit set by ProGet to the size of a feed, and we have customers with terrabytes of packages, so it should be okay.

Hello;

Kaspersky is totally wrong. This is a 100% false positive. Can you share this thread with them?

LoupeViewer.exe is a tool that, among other things, inspects MSIL of live processes for debugging purposes, and it's embedded in our installer. It seems their (or whatever provider they use) heuristics algorithm saw an ".exe that embeds an .exe that uses MSIL inspection hooks like this", and flagged it as this signature.

It shouldn't take more than a few seconds to verify that LoupeViewer.exe is not a trojan, and it'd be easy to inspect the disassembly.

Microsoft and several other providers have already removed whitelisted this in response to other customers submitting this.

Our installer is safe. Rest assured that if the package is signed by Inedo, you can be absolutely certain that no "viruses," malware, Trojans, or other malicious code were injected into our installers.

Please see this article for more information: https://inedo.com/support/kb/1113/false-positive

Hi Stijn,

The PowerShell client is indicating that there's an error downloading that file, and that when it tries to open the package (which is a zip file), it's corrupt.

I don't know what the error is, but if you follow that URL in your browser, you should receive a .nupkg file. If you can open it up as a zip file, and it opens ok, then the error might have to do with a proxy server, or something, that's corrupting the fileon the way from ProGet to PowerShell?

Hello;

We are aware of the vulnerabilities.

Our usage of this library is minimal, and we do not use it in a manner that would impact product security (i.e. "passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others). So please consider this a "false positive".

Upgrading the library to 3.5.0 would add no value to ProGet users, but it would provide significant risk of UI regressions and risk of introducing unknown security vulnerabilities, that haven't yet been reported.

Aaand, published :)

Appreciate verifying & helping us finding this bug.

Just a quick in-progress preview of what we've got coming; feedback welcome!

UPDATE: Conan support is here!

https://docs.inedo.com/docs/proget/feeds/conan

Are you actually using Conan?

I've talked with a lot of users over the years about C/C++ development, and the emergence of Conan, and after a careful evaluation, not a single user opted to not use it due to the complexity it adds. Some instead switched to NuGet (which supports C++), and others just use UPack / Universal Packages.

So far as I can tell (I'm not a C/C++ developer), the big challenge is that Conan "wants to be" a cross-platform open source hub (like the NuGet.org of C/C++), but C/C++ isn't cross-platform, and there's no real standardization in how you configure C/C++ project, so the Conan platform has to jump through a lot of hoops to make it work.

~~From my understanding, you need to make "recipes" that are like a kind of installation script, and these are written in Python (??), and executed using Bash. So, on Windows, that many more steps to follow. ~~

Another problem I heard was development environments vs target environments. Like how you can code on Windows, but your target is embedded something, so it adds a whole new layer of complexity. I also remember something about, building from source vs libraries, and how it was a lot of work to get it to work the way you want.

Our customers had zero interest in taking open source packages from the Conan's public repository; it was only for their own, internal-use packages.

Again... this is all second-hand for me, so, if you have more insight please add it.

@olivier we're mostly still looking for insight/answers into the questions @gdivis had asked, so if you can help on this we could at least move the ball forward

@gdivis said in Support for R and CRAN:

1. ProGet typically needs to understand versioning rules for packages (to show which is the latest, to do retention policies, etc). From what I've gathered, CRAN uses 2 or more integers separated by dots. Does anyone know if that's required universally, or if it's just a convention?
2. CRAN doesn't appear to have a server-side repository API, instead just exposing a list of packages using HTML. Is my understanding correct here?
3. Submitting a package to CRAN looks like it's only done manually using a form here. Is that right, or is there some other automated mechanism that is used?

Thanks for the additional info... I definitely appreciate the desire for consistency in package management.

we have to manually copy down the packages

Why is this? Is there a sort of internet restriction policy in your build environment?

What do you mean by "drop in value"... is it like, "we already have ProGet, and it would save X amount of time to not have to create/manage a separate, private Conda repository"?

I spent a bit of time looking into CONDA, and here's my take.

According to the documentation, "in its default configuration, conda can install and manage the over 7,500 packages at repo.anaconda.com that are built, reviewed, and maintained by Anaconda."

This leads me to believe that the primary use case for Conda is to gain access to the curated package repository for data scientists that use the Anaconda development platform.

One of the major value propositions of ProGet is that it gives you the ability to curate free and open-source packages... so I don't see how ProGet will help? I could be wrong... but I'd really want to see some market demand or more customer demand for this before we consider investing engineering resources.

While it seems that Conda could also be used for other cases (they say "it was created for Python programs, but it can package and distribute software for any language"), the documentation is almost entirely focused on the primary use case.

If you're using Conda in it's second usecase (as a sort of generic package system), ProGet already has Universal Packages built in. These were created for first-party application and components (first and foremost), so they will likely be much more suitable than the secondary case of Conda

Ah, you must be running this against a Linux-based server; I don't the error message is very clear, so I've already changed it in the code); hopefully this is more clear now:

To use Git-based operations on Linux/SSH-based servers, you must specify a path for the Git executable. This can be configured on the operation, or by creating a variable named $DefaultGitExePath, which you can scope to the server, role, etc.

@markcodyre_7146 thanks for the note Mark, I appreciate it! Glad it's working well, despite the challenging install - we've got a lot of great container features in the pipeline, so hopefully we'll learn more about Linux in the process ;)

Definitely sounds like a bug; we've get it logged.

By the way, we've got some real exciting container/registry features coming very soon in ProGet 5.3. Stay tuned!

Great solution, thanks for sharing @Zazcallabah

Our (paying) customer hardly ever configures ProGet in this manner, and we aren't exactly Linux experts so writing documentation on seemingly dozens of different ways on how to do this sort of thing is really tough for us.

I'd very much welcome your contribution to our documentation, it's on GitHub (just click "Propose an Edit" at the bottom): https://docs.inedo.com/docs/proget/installation/installation-guide/linux-docker

I want ProGet to be a great community tool, and hope you can help contribute to the Linux installation experience; thanks!

This is, unfortunately, a known versioning bug; see the "PowerShell Module Package Version Quirks" section in our PowerShell Feeds documentation.

I recommend you to escalate it and ask the folks at Microsoft to fix it; if enough people ask, I'm sure it will eventually be addressed.

Actually, I'm not wrong; ProGet is simply not designed for your use case. It is infinitely more stable in the use cases it was designed for. ProGet also can't bake you muffins; an "oven" is much more suited for this purpose.

There are lots of tools that solve different problems, and ProGet is not designed as a desktop-based, single-user "server" for personal use. We have no intention of building such a tool; our tools are designed for teams to work together, not power tools for single users.

Anyways, it looks like found the tool that you're looking for. Best of luck.

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..