Posts made by atripp

There is a task attribute called "Delete Package". Just make sure you have a Task that has that attribute. You can see more info about it here:

https://inedo.com/support/documentation/proget/administration/security/creating-tasks

ProGet most definitely does not "lose package" on an upgrade, so there must have been some sort of configuration change, either in the ProGet software (retention policy, package store), or external to the software (files deleted from disk).

It's highly unlikely that this configuration changed as part of the upgrade, particularly from those versions. Most likely, your database backups just happened to be dated from before the upgrade because the installer will auto-backup for you; so, the upgrade is really a red herring. You can search ProGet's audit logs to see if anyone in the software deleted them.

But regardless, if the package files are gone, and you don't have them backed up (the installer will not do this for you), then they are gone. There's nothing you can do, so I think your idea of searching for fragments from user caches, and then uploading those, is the best you can do.

NOTE: Unless you explicitly configured a retention policy for ProGet to delete files, the software will not delete these files on disk. Even when you delete a feed or uninstall the software, the package files remain. We do this for safety purposes.

Please make sure to read our backup and restore instructions.

Definitely not, they are on the low-end of the medium size... and just to be clear you shouldn't be calling dbo.Dashboards_GetDashboardInfo with more than 10 packages. It's only designed/tested for 0, 1, and 10.

Based on the table sizes and distribution, there's no reason it should be performing so slowly. Actually it works fast even on instances with 100x the packages that you have.

Maybe there's something else with your data that we can't see based on the tables you sent us. You should be able to view/edit the code of the procedure and underlying database views; perhaps you can find something by investigating the queries and data relationships?

Without seeing your log, I really don't know. But in this case...

WARN : 2018-02-21 22:37:21Z - ID: 107;	Name: BUILD-SOURCE;	Scope: Release

We have a legacy release template variable called "BULID-SOURCE". This will only show up in an application's settings page, it will not show up under global.

So how can we find the application? well, if I run this query, SELECT Scoped_Application_Id FROM VariableDeclarations WHERE VariableDeclaration_Id=107 I can find the application id. From there, I can enter it in the navigation bar, and find the variables.

Yes. But hmm ... maybe it's a disabled application? You should be able to find those in the VariableDeclarations table; those IDs refer to those.

These Legacy Template Variables (Release, Build, Execution, Promotion) are defined at the application-level, not at the system-level.

If you View Full Log, you should be able to find a block that looks something like this:

WARN : 2018-02-21 22:37:21Z - Legacy template variable declarations found:
WARN : 2018-02-21 22:37:21Z - ID: 107;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 92;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 108;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 109;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 111;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 112;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 113;	Name: BUILD-SOURCE;	Scope: Release

If that's not enough information to locate, you can look directly in the SQL Server Database to find out.

I'm afraid I don't really understand the requirements for what you're trying to accomplish...

Here are the differences between the two extensibility points:

• A Package Filter allows all locally-stored ProGet packages to be filtered from being shown in feeds by additional logic.
• A Package Access Rule Allows for rules to block downloads of packages based on additional logic.

The Package Access Rule is used by the Whitesource extension, so you can reference how that works. We don't have any publicly available uses of Package Filters; it was incorporated for a very specific usecase with publicly-available feeds.

I'm sorry, I accidently replied to here instead of this post. Please disregard it; the issue has nothign to do with your license.

I don't have an answer to your question, but another engineer will help soon. Note that if you have a paid license you can use a support ticket.

But someone will respond to this soon!

Yes, it just involves changing the license key.

Please refer to License Key Management

I'm afraid we don't have a guide on Azure-hosted AD at the moment, but from talking with other customers, they said they used the Advanced Configuration documented here https://inedo.com/support/documentation/various/ldap/ldap-active-directory

Single sign-on is unscheduled so I don't have a timeline, but it seems quite soon from what 've heard... 2019/Q1 or even Q4.

ProGet already supports Azure-hosted AD Authentication; if you're looking for Federated Authentication (single-sign on), that support is coming across all of our products.

Yes, it just involves changing the license key.

Please refer to License Key Management

ProGet calls the procedure on those pages 10 and 1 for Packages_Count. If it's really slow at 10 packages, you may want to try rebuilding/defragmenting your SQL Server indexes.

Good questions;

1. You can configure ProGet to block packages with "unassessed" vulnerabilities; this is not the default configuration because a lot of times vulnerabilities are discovered after you've already been using a package anyways

2. That's true, but maybe we could expand webhooks? I'm not sure, but it seems like it could be a feature request if it's something you'd actually want to use, etc.

Hello; just to let you know, the Inedo ProGet Plugin for Jenkins has been updated, and may work better.
Have you had an progress onthis otherwise?

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/

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?