TFS labels can be a bit complicated, and the way that Visual Studio (GUI) vs tools (tf.exe, BuildMaster, etc) interact with them are different. What may be happening in the GUI is that multiple labels are being created with the same name, and the the GUI is "searching" for files by label name (as opposed to "getting" those files).

If you were to do a tf.exe get (https://docs.microsoft.com/en-us/vsts/tfvc/get-command?view=vsts), for example, you should see the same behavior. Instead, makes sure to first create a label at the $/ root level (e.g. tf label myLabel $/ ), and then you can sub-label items.

Hello; please check out this KB article for help on how to update the urls.

https://inedo.com/support/kb/1014/changing-an-inedo-products-url-with-the-integrated-web-server

Alternatively, you can use IIS, which will be easier for your web admins to maintain.

It may have been a temporary outage, or a proxy problem, or something. You can ignore it. If you restart the service it will probably go away.

Hi Sebastian,

You can access all of the DNC packages using the ODATA (v2) protocol API.

If you're finding an issue with it, it's totally unrelated to the API protocol. Please submit a different question with specific packages, reproduction steps and we can investigate

Cheers,
Alana

ProGet runs fine under a domain account.

The Inedo Hub is the desktop application used as an installation center, and doesn't impact the way ProGet is run. Next time you see an error with the Hub, please send us the error report so we can investigate it better.

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/