Posts made by atripp

This particular error (the 500) will be fixed with PG-1313

This will be fixed with PG-1313

PublishLocation is where you publish packages to, and SourceLocation is where you download packages from. It's typically the same, but sometimes it isn't.

Please don't forget to mention ProGet in your article as a good private repository ;)

A package is uniquely identified by its version, so different package versions will need different numbers. But I think you can use the pre-release labels, at least in some sort of way to do product support?

Take a look at this video from our recent Hedgehog webinar: Using Semantic Versioning to Overcome Package Deployment Challenges. You can see the whole webinar on the Hedgehog page as well.

Universal packages support SemVer2, which is a three-part version number scheme with additional labels for pre-release and build metadata.

The NuGet "4-part" scheme was proprietary, undocumented, and had very strange quirks and behaviors, which is why NuGet has deprecated it years ago.

If you absolutely need to use a proprietary/non-standardized version number, then I recommend you to just add it as metadata to the package (_myVersion or _componentVersion) .

Otter, BuildMaster, Hedgehog, and ProGet for Windows all require any supported version of Microsoft SQL Server. So, 2017 would be supported, since Microsoft supports it still. 2005, however, not.

Hello Telly,

Is your Docker feed named docker in ProGet? I get this error when I try to push to a feed that doesn't exist in my local ProGet instance.

Hello Dwight,

This should be logging an error message, but it's not. I've filed PG-1311 to fix the lack of a useful error. I've attached a modified build of ProGetCoreEx.dll to PG-1311.

If you replace ProGetCoreEx.dll and try this again, is there a warning message starting with Unable to open file in /administration/logs?

This is basically an error reporting an error; it can sometimes happen, and thus it masks the underlying error. The usual cause is the client disconnected unexpected, and the error can't be reported.

You can switch to INTEGRATED PIPELINE mode to see the full error

I'm afraid there's not any further configuration. This will happen on any server, physical or virtual, when the SQL Server cannot be contacted.

It's usually related to network connections, or the SQL Server is just totally bogged down from other things. See if rebooting fixed it, that will often help.

Since this is anew installation, why don't you totally start over (Delete the database).

Then, make sure that when you create the database, your user will be in the "dbo" schema. Then it should all work.

I see, so you're saying that that the ReSharper client appears to not work with a ODATA/v2 API? In this case, this is most certainly a bug or a misconfiguration and you should share/communicate it to JetBrains.

There is virtually no support in commercial or open source private repositories for JSONLD/v3. While it's on our roadmap to implement, it wouldn't come until late this year... and obviously it would require upgrading your PRoGet server software, which many organizations don't like doing for at least 6/12 months after a release (especially for something like ProGet).

So, this would effectively makes ReSharper unusable for private extensions.

I'm not familiar with Zabbix, but there are two things you can do to check about the status of the components (Database, Web, Service):

• If the database (SQL Server) wasn't working, or there was a problem with the website configuration, then visiting / will yield a 500 or some other not available message.

• You can just query the ProGet service run state directly.

• You could parse the text on the /connectors page or use the native API to get a status of the connectors.

This is by design; it is the responsibility of a package author to license a package, and make sure that it's a standard license. This way, automated licensing monitoring can catch it. However, as you've noticed, this isn't the case for a lot of open source packages.

So, in this case, you'll want to use a different workflow. Just create a "approved packages" feed, and promote approved packages into these feeds.

We don't test with this, but I looked at the website...

https://resharper-plugins.jetbrains.com/

... and it appears to be a clone of NuGet gallery. As such, it seems you can use this URL:

https://resharper-plugins.jetbrains.com/api/v2/

This will be addressed in next maintenance release as PG-1294 . As a workaround, you can access the package directly by version number even without this fix.

Your best way to do this, would be to use the nuget client, and then pull the cached packages to your feed.

"Pulling with dependencies" as a feature in ProGet would require implementing every dependency resolution algorithm of every version of every client, including the non-deterministic dependency resolution used by the npm client, and then somehow letting you select the algorithm version and the additional content required by the algorithm (such as .net framework target version).

unfortunately this bug fix just missed the cut.

But we will ship it in the next maintenance release, likely in a couple weeks. It's not scheduled yet.

Hello; it's hard to say what the particular issue was (perhaps, a temporary server outage), but you can always go to https://my.inedo.com/ and request a key then enter it in the installer.

I'm afraid Linux doesn't support Windows Integrated Authentication.

As a work-around, you can create a second site in IIS that points to the same path, but doesn't have Windows Integrated Authentication enabled.

Hello; it's not the drop path, but the package source path. You can set this in the ADmin > Advanced Settings, and also in each feed.

No problem, I've filed PG-1277 so we can make sure it's done everywhere!

The Inedo Hub is still in Beta, but we plan to have it support individual components of a tool, such as ProGet.Web. You will also be able to do something like, romp install ProGet.Web to just install/configure the web package.

We're also going to be shipping the "legacy" installer (probably won't call it that ^_^), as an alternative option for people who set up automations.

For now.. you can use same process.

Hello; I've added a feature request for this.

There is no ability to do a "mass edit" like this I'm afraid.

Hello;

Inedo.com currently seems to only communicate over TLS1.0; I don't have a timeframe for when that will be upgraded, but I want to add that we don't have any secure or sensitive information on inedo.com anyways.

In the case of LDAP, it seems to me that there is some sort of issue with the LDAP code mapping your username. AD configuration can be very complicated I'm afraid, and it will involve a bit of back-and forth, with sharing potentially sensitive or company-identifying information.

When you search for a user in ProGet, you will see a log of the domains, etc., being searched. Ifyou can publish that to a ticket, then we can investigate further.

You can use Tasks (Admin > Tasks) to restrict who can access which feed. Once you've restricted a feed (i.e. not give permission to Anonymous), then users who access it will be prompted for credentials .

The "protocol/API" (ODATA vs JSON-LD) really doesn't make an impact on this.

In ProGet v5, NuGet feeds to in fact support SemVer2 packages. If you're finding errors, then you may have a legacy feed: please refer Legacy (Quirks) NuGet Feeds for how to migrate. Otherwise, if you have specific error cases that we might be able to try to reproduce, please let us know it.

Hi Josh,

Sorry, this seems to be a v6 glitch! But we're on it :)

I've submitted BM-3192 and then inedo-docs/#6 to update our documentation.

Your understanding of how the feature is supposed to work is correct, and your use-case is how it's supposed to be.

Thanks for reporting it !

hi Keith,

We definitely plan on having an offline process, and welcome your feedback on it.

You can read a bit about how the hub works (it's in beta, so please forgive the rough docs). Specifically, check out "Configuration and Offline Installs":

https://inedo.com/support/documentation/proget/installation/hub/inedo-hub

The Inedo Hub wraps Romp (more coming soon on that), so you could also use that to install ProGet as well, as a command line process.

Does that help?

You shouldn't be receiving a "401" error from the public npmjs registry. If you are, my guess is that you have some sort of proxy or firewall selectively blocking outgoing access to certain queries to the registry.

Once you resolve that, then p[roblem #2 will also be resolved.

We don't have any guides on this integration specifically, but the usual situation is that TC can't authenticate. The easiest thing to do is to allow anonymous publishing to the feed, but not overwriting.

Otherwise, you can try to get the authentication to properly work, which typically involves sending username/password or configurating an API key properly.

The documentation seems incorrect :(

Can you try?

http://proget-server/nuget/feedName/package/{feedName}/{packageName}/{optional-version}

PG-1054 was released in 5.0.9.

In this case, it seems like your machine has no internet access, and can't request a key from my.inedo.com; you can do it manually from that website.

You can request it at my.inedo.com, or just ask as a note on the Otter Quote Request Form. What's nice about going through the pre-sales/quote process, is that we can work together beyond just random forum / Q&A posts, as obviously we are generally motivated to help you prove a success to enable a sale ;)

That is indeed the correct behavior; the express edition is intended to make all users an administrator.

However, we are thinking of adding a new "mode" for express edition that will behave more like you desire: unauthenticated users will be able to view most everything, and authenticated users will be administrators.

In the mean time, why don't you just request an enterprise trial key? We understand that it can take while to totally prove out, and of course we will work with you to extend the trial key and help you prove the capabilities.

Hello; please fill out the contact form, and we will be able to you via email.

I see, that's an interesting idea. It seems like some sort of auto-generated documentation of sorts? I don't know if ProGet is the place for that data, but we don't have a feature to store such doumentation at this time.

So, maybe you could auto-post it a documentation wiki of sorts and use the "Project URL" property to link to it?

I'm afraid there's no easy answer for this.

First, keep in mind that dependency resolution is really complicated (see NuGet Docs to get an idea), and it seems some package managers (like npm) even have a nondeterministic (let alone undocumented) algorithm for resolution.

The only thing that "mostly knows" what packages are actually being used are the client tools themselves (nuget.exe, npm, etc), and you'll really only know what dependencies they've grabbed after you see the packages on disk.

ProGet has package statistics, which at least shows you which packages are being requested. But nuget.exe puts more information in the requests, so all ProGet "sees" is a request for a package from a address... and often, multiple requests happening in parallel.

Hello; this is not currently support in BuildMaster, but we may consider adding it.

However, it is already built-in to Hedgehog, which is more suited for lots of uniform style applications.

Unfortunately this is a bit tricky to give "general" advice on how to fix, but if you can submit a specific test case that we can reproduce as a ticket, we can research and try to reproduce it,.

The "remote icon" means that there is a package entry in a remote server. If you're continuing to see it, then it may take a little bit for the connector metadata (in memory)cache to be cleared. You could always stop/start the webservice, and then this will go away.

This should be cleared if you try the installer again

You can mirror ProGet feeds, but we don't have a Maven <> Maven repository option just yet.

It's a "401" error, which means "not authorized"

In this case, you could have the wrong credentials in Yarn (or no credentials). Note that "Windows Integrated Auth" is not supported by npm or yarn.

Are you using a "Legacy NuGet Feed" (created in v4), or is this a "new" (SemVer2) NuGet feed?

Leading zeros are no longer supported by Microsoft for NuGet packages, nor the ProGet SemVer2 feeds. So if you are still using them in your process, you really ought to change your process to use semantic versioning.

This is by design; accurately paging in the UI is basically impossible due to limited connector aggregation, package filtering policies, etc. Especially after you do a search.

Instead, you can display "up to 1000" packages in the UI, which is probably more than you would ever need to scroll through, and search as needed.

The error is "failed with: 401 Unauthorized", so it probably means you need to specify an authentication source?

We didn't change the way authentication is handled in v5, so it's likely unrelated to the upgrade.

I'm not too familiar with how OneGet fits into all this; you'd really be better asking this question at the Chocolatey or OneGet forum. You'll still use ProGet to host the packages, but I'm really not sure which client tool (choco, etc) will do the download and install on a desktop.

You'll want to use Chocolatey for this purpose; it's designed to install Windows software.

The PackageManagement module is intended for powershell modules for your PS runtime environment.

Both of them use NuGet behind the scenes, but we still recommend to create the appropriate feed for the type.