Posts made by atripp

@torgabor_4445 one other thing to try -- how about just putting your token as the password, and then having no username? But still selecting Bearer auth?

Hi @itinfrastructure_7135 ,

I researched this some more, and it looks like it's also configurable per-user. So you'll need to change the regional setting of whatever account ProGet is running under it looks like.

I've never done this before, and it's something handled by the operating system... but I searched " change regional settings per user windows" and found a number of results, but this one looks promising: https://docs.microsoft.com/en-us/answers/questions/254248/default-global-regional-setting.html

Hope that helps!

Cheers,
Alana

Hi @itinfrastructure_7135 ,

Did you restart the server? The setting is at operating-system level, so you will need full reboot of server.

Cheers,
Alana

Hi @jim-borden_4965 ,

I think the iconUrl will be relatively easy to implement, but not so much the licenseUrl...

Can you provide a download link to a package that I can test with? If it's easy we can make the fix for iconUrl.

Cheers,
Alana

Hi @torgabor_4445 ,

I believe that, when creating the npm connector, you can select "Authentication: Bearer", and then enter email and your token for the username.

Let us know if that works!

Cheers,
Alana

Hi @jerome-jolidon_1453 ,

Looks like you found the place where that was fixed; that query is a weak point when there's intensive database logging. About the only time that happens is when the server is overloaded with a traffic spike and starts running into database connection errors. So those just pile up.

It could also happen if some one left on Feed-level logging (Admin > Advanced setting, we do not recommend it).

Cheers,
Alana

Hi @itinfrastructure_7135 ,

Dates in ProGet are stored as utc datetimes, and then are displayed using .NET's date formatting functions, which in turn uses the operating system's setting.

So I guess, if you just restart the server, maybe the setting will take, and dates will be displayed as epxected?

Cheers,
Alana

Hi @blake-meike_5923, hi @jim-borden_4965 ,

The "bulk delete" is in ProGet 2022 - you just navigate to "Packages", click "bulk edit", and select the ones you wish to delete.

Otherwise we haven't implemented a DELETE endpoint for Maven artifacts, so it's not going to be possible programmatically until we do. Unlike the NuGet client, the Maven client doesn't have any delete capabilities and no one else has asked for a custom API endpoint.

In ProGet 2023, we do intend on making an API that would work across all package types, but that's a whiles off. We can consider adding and documenting a custom Maven DELETE endpoint, but the use case of "working-around a paid feature" isn't exactly a big motivation for us to prioritize a change

Cheers,
Alana

Hi @laxmi-salunkhe_6251 ,

It sounds like you're new to ProGet; do you by chance have someone on your team who can help show you how it was set-up, and how to navigate?

A few points...

• You are viewing the "Packages" page, which only shows your local packages. You can increase the number of packages shown by changing the "Count" drop-down box.

• You can also search your feed by clicking on "DevCurrent" (or navigating from Feeds > DevCurrent), and then searching.

Thanks,
Alana

Hi @laxmi-salunkhe_6251 ,

I'm really not sure how I can help with this....

Please provide more information, screenshots, etc.

Thanks,
Alana

Hi @jeff-peirson_4344 ,

Looks like the docs were wrong, thanks for bringing that up.

It should be PROGET_SQL_CONNECTION_STRING_FILE -- I've since updated the docs.

Cheers,
Alana

Thanks for the update @inok_spb, that's quit helpful.

Looking at the code, I think I could see how that could happen. The code isn't very pretty and it's a bit complex. Unfortunately, it's not simple to reproduce (for me), and the issue is low priority since no one else has reported (except just single free-edition user).

However, if you can modify the stored procedures, then I can give you some pointers on what I would do to investigate. If you can fix the stored procedure on your server, then we can modify our source code, and the issue will be resolved!

The first thing I would do is modify DockerImages_SetData as follows by moving the following line of code to the top of the code block, right below the BEGIN TRANSACTION statement:

DELETE [DockerImageLayers] WITH (TABLOCKX)
 WHERE [DockerImage_Id] = @DockerImage_Id

I don't think a TABLOCKX is appropriate here, but regardless -- moving this to the top should block DockerImages_GetImage until the procedure finishes. I don't see any other side-effects from making this change.

If you have someone who is really skilled in SQL Server, then I'm sure they could do a better job than I would, but this is where I would start.

But please try this and let me know!

@paul-regan_9353 unfortunately not :(

It wasn't a quick/trivial fix unfortunately, and we couldn't dig deeper last week due to vacation/holiday. We scheduled time to review deeper this week!

Will update / post link a product issue or bug as soon as we learn what the issue is.

Hi @pariv_0352 ,

At this time ProGet doesn't support those version numbers for NuGet packages.

Here are the rules we currently follow:
https://docs.inedo.com/docs/proget-feeds-nuget-semver2-and-legacy-versioning#legacy-nuget-version-numbers

2.8.2.1-preview.79 is supposed to be an invalid version, and it wasn't allowed to be uploaded to NuGet.org for very many years. But I guess, they changed the rules....

This appears to be a newer packages, so we will consider changing the rules of ProGet. Please stay tuned... I'll update after discussing to the team.

Cheers,
Alana

Hello,

This is related to a known issue that's been addressed in ProGet 6.0.19 and ProGet 2022.5. So, your best bet is to upgrade and the issue will become resolved :)

This is related to an few packages that have exceeded 2.2b downloads:

• Microsoft.NETCore.Platforms
• Microsoft.Extensions.Primitives
• Microsoft.Extensions.DependencyInjection.Abstractions

If upgrade is impossible/difficult right way, then as a work-around, you can disable the connector. Alternatively, you could block those packages with a connector filter then upload them to your feed so that the counts won't come through the connector.

Cheers,
Alana

Hello,

I can confirm, I've got the same error. This is likely due to "bad" data in the feed; we've seen a couple others with that.

We'll investigate and work on a fix :)

Cheers,
Alana

@sdohle_3924 so far you've been the only other person to ask it :)

It's very complicated from engineering standpoint, and there hasn't been a lot of demand for it. Good to know that you're interested.

It's likely not going to make our roadmap in the near future, but perhaps next year we can consider it.

Hi all,

This is a known issue, and it's addressed in ProGet 2022.6 and
ProGet 6.0.19.

It seems to come from these three packages:

• Microsoft.NETCore.Platforms
• Microsoft.Extensions.Primitives
• Microsoft.Extensions.DependencyInjection.Abstractions

As a work-around, you can block those packages with a connector filter, or upload them to your feed so that the counts won't come through the connector.

Cheers,
Alana

Hi @mike_2282 ,

If you want to use HTTPs, at this time you'll need to use IIS. It's really really easy to configure, which is why we prefer that instead of writing our own management interface for certificates.

Here's our guide for switching to IIS:
https://docs.inedo.com/docs/various-iis-switching-to-iis

We don't have a guide for "enabling HTTPS on IIS", but there's a ton out there.

If you don't have a org certificate, then just use https://www.win-acme.com/

That is a tool that will configure an IIS Site for SSL (using a certificate from LetsEncrypt), and and then created a scheduled task on Windows to renew that certificate every 90 days (i think).

1. Download the latest stable https://www.win-acme.com/ and extract to c:\win-acme\<file-name>
   -> Example: C:\win-acme\win-acme.v2.1.14.996.x64.trimmed

2. Run wacs.exe as an admin

3. Run the "Create Certificate" option and select the site(s) to create certificates for; this process will be pretty self-explanatory, and will create scheduled jobs to renew the certificate

4. verify that you can now access your site via HTTPS as you expect

Note that certificates renew every 90 days (i think), so set a reminder to check before your users do.

Cheers,
Alana

Hi @rie_6529 , thanks for the forum post!

This looks like it's a regression - we'll get it fixed in the next maintenance release (scheduled this Friday) as PG-2180

Cheers,
Alana

Hi @jblaine_9526 ,

I can't find anything about SAML group claims on our internal roadmap... is there a ticket/forum post about it that I missed?

Cheers,
Alana

Hi @inok_spb ,

There won't be any issue in disabling that trigger. It's basically like a "foreign key constraint", and just checks for data validations. However, I suspect its where the problem is, so please give it a shot and let us know.

We haven't had any other reports of this, tried to reproduce on our own, or fix it.... so it's not surprising if the issue is still there

Cheers,
Alana

Hi @bushman_3007,

Can you clarify the request some more, i.e. why are you wanting to delete soft-deleted directories?

I don't know the reason directories are soft deleted, but I suspect it has to do with preserving versioning history.

Thanks,

Alana

Hi @mcascone ,

This is a bug, thanks for the report!

ProGet "soft deletes" items, but it seems when you go to recreate a directory it's not set to "not deleted". We'll get this fixed in the upcoming maintenance release of ProGet 2022.4, scheduled for August 12: PG-2173 FIX: Deleted asset directory items cannot be created

Cheers,
Alana

Hi @inok_spb

I think you're right, something must be deadlocking.

There was a database change in ProGet 6.0.16 that basically involved creating a large transaction to handle a race condition.

https://inedo.myjetbrains.com/youtrack/issue/PG-2140

We haven't heard of any other reports of this deadlock (particularly from our paid users)... and unfortunately deadlock issues are really hard and time-consuming to reproduce and track down (especially with Docker using shared layers).

So as a free user, we'd really appreciate any other info / help you can provide to track this down and fix :)

The issue would most certainly be in database code, which is viewable/editable in SSMS.

One quick thing to try -- can you just disable TR__DockerRepositoryTags__ValidateImage? That might be the culprit... and if so, we can always add it to the stored procedures as well.

Cheers,
Alana

Thanks much @brett-polivka !

That's a great tip! That just might be it, and I can see the code here just uses Uri, as opposed to a Sas URI:
https://github.com/Inedo/inedox-azure/blob/master/Azure/InedoExtension/FileSystems/AzureFileSystem.cs#L91

For that error, can you see what ProGet logged in Admin > Diagnostic Center?

Hi @a-diessl ,

To simplify things, I'd recommend just hosting ProGet in IIS and using ACME/LetsEncrypt... if you don't already have HTTPS.

I can't answer why the domain is being set, that's just something the hosting framework seems to do, and it hasn't been an issue (for Linux users) until now.

We'll definitely consider changing if it becomes more of an issue...

Cheers,
Alana

Thanks for the detailed investigation!

You're right, the cookie domain seems to be the problem.

We are now using .NET6 on Windows, and I'm guessing that's how you're hosting this? This would have behaved the same on Linux (which was using .NET5 for a long time).

The cookie domain comes form the hosting framework, and doesn't use Web.BaseUrl. In general, we don't recommend using that anymore, and instead prefer the X-Forwarded-* headers.

In this case, can you try setting a header value on your reverse proxy to use X-Forwarded-Host: proget.example.com? Then it should work.

I haven't tested it, but since this is what's generally done on the NGINX proxies, I suspect it's not a problem

Hi @brett-polivka ,

In ProGet 2022, we upgraded to a completely new version of the Azure SDK, since the old version was long since deprecated. So, it's not unexpected to see issues... though we didn't see these in our testing :)

I'll do my absolute best to help! Our code doesn't really deal with authentication or access rules; that's all handled by the Azure SDK, which uses that connection string.

I searched "CannotVerifyCopySource", and a lot of SDK users (including tools like AzCopy) repot this issue when switching to the new SDK/API. I don't know Azure well enough to undersatnd, but some said that it had something to do with "storage account firewall".

Beyond that, I'm not totally sure how to troubleshoot, but the first thing that comes to mind is the connection string. I'm not sure what to look for, but I know those can get quite complex... and maybe you're using a option that behaves differently in the old vs new sdk? Maybe you need to specify something in the connection string now?

Here's some docs on connection strings:
https://docs.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string

The second thing I would try is to create a totally new Azure Blob Container, using the default settings, and a very basic connection string. That should work (that's what we do), and then try to compare/contrast the differences between the containers.

Please let me know what you find!

Cheers,
Alana

Hi @v-makkenze_6348

I'm not sure what else to change... how about changing the ".NET CLR Version" to "Integrated" or "No Managed Code".

The Inedo Hub should automatically do that for you.

Thanks,
Alana

Hi @marcelo-carvalho_9635 ,

In this case, you'll want to switch to IIS hosting:
https://docs.inedo.com/docs/various-iis-switching-to-iis

You may find it easier to uninstall/install as well (note: the database will remain the same, and nothing is deleted).

Cheers,
Alana

Hi @marcelo-carvalho_9635 ,

This is configured outside of Otter, and is handled by the web server - either IIS (Windows) or nginx (Linux/Docker).

Getting HTTPS on Windows is "relatively easy" - you can use something like WInACME to install a LetsEncrypt certificate, or you can install one issued by your organization. We don't yet have step-by-step documentation on how to do this , but it's something we're writing.

Here is instructions for Linux:
https://docs.inedo.com/docs/https-support-on-linux

Is that helpful? Please let me know :)

Cheers,
Alana

Hi @Panda ,

That sounds like a great idea; I'm afraid we won't have the resources to add this in the coming weeks (we have some really cool stuff planned for BuildMaster 2022 that we're working on now).

The easiest way to do local-development on the extension is to get the source code from GitHub, then build it into dll. Then, construct a new version of the Subversion.upack file with your DLL, and replace the one in the existing extensions folder. From there, restart the web/service, and your version should load instead.

If you add properties to SvnRepositoryMonitor.cs that look like the other properties, they should show-up in the UI and be configurable.

Let us know what you come up with, and we can definitely merge in the code and release a new version with your changes.

Cheers,
Alana

Hi @bbrown2_8761 ,

It's a bug in Visual Studio's NuGet client I'm afraid and it's not something we can realistically work-around

You could post it in the NuGet issues, and they may fix it in a future version; https://github.com/NuGet/Home/issues

It's really easy to reproduce, and they've definitely fixed issues like this in the past.

Cheers,
Alana

Hi @Panda ,

I'm not really familiar with SVN, but I'll do my best to help :)

It looks like our code just assumes that there is a /branches directory, and that's why it's crashing.

The repository monitor will enumerate the branches to find the most recent revision numbers, and then trigger builds as appropriate.

The code that enumerates branches seems to do the following call svn ls --xml "«repo-url»" "branches/", and then parse the results. But it's failing, because svn is erroring with E200009.

So it would require some sort of code change to get this working. Perhps a flag on the repository monitor, or something like that? If you have any ideas, maybe it's something we can try -- it's easy to get pre-release versions out there.

Cheers,
Alana

Hi @bbrown2_8761 ,

I was able to reproduce this issue, though it's not happening 100% of the time.

• a feed with a connector to nuget.org will fail
• a feed with just that version of the package will work

So far as I can tell, it's a bug in the NuGet client that .NET Framework uses. Maybe it's a result of the "bad version" in the feed?

We can see that Visual Studio is requesting the registration index, and then complains the package isn't found. However, it's clearly in the index.

The registration index lists all versions of the package, and you can find it on this URL:

https://(redacted)/nuget/approved-nuget/v3/registrations/selenium.webdriver.chromedriver/index.json

You will see 103.0.5060.5300 in that list, and there's no reason NuGet should say he's not found.

There is one key difference between ProGet's registration index, and NuGet.org's index is paging. Here's NuGet's index:

https://api.nuget.org/v3/registration5-semver1/selenium.webdriver.chromedriver/index.json

When the registration index is paged, then the client will look for the appropriate page. I'm guessing he will crash if there's a bad version in there, or something?

Anyways... I don't think we can do much to work-around this issue, and I guess you have a suitable work-around: don't use the Install-Package command. That seems to be the only thing broken.

Cheers,
Alana

Hi @mcascone ,

Thanks for the feedback, that's great to hear. We'd love to hear what your download instructions look like, so we can share examples of how to use it.

We didn't have support for this, but it will come in the next (first!) maintenance release of ProGet 2022, currently scheduled for July 8:
https://inedo.myjetbrains.com/youtrack/issue/PG-2157

Cheers,
Alana

Hi @Chester0 ,

That screenshot appears to be the place where you configure environment variables? There's just one environment variable, and it's SQL_CONNECTION_STRING. The -e indicates to docker client that it's an environment variable, and isn't part of the environment variable name.

The rest are other configuration options that instruct the docker client to work in one way or another. They're not environment variables. This is kind of complex to configure use unless you really know Docker inside-and-out, and know how to apply concepts to another engine.

You may wish to use Lightsail and Windows. The costs are about the same, and the Inedo Hub is much easier to work with:
https://docs.inedo.com/docs/proget-how-to-install-on-aws-lightsail

Cheers,
Alana

Hi @Chester0 ,

I'm really not familiar with AWS Fargate, but it looks like this is how you're supposed to pass environment variables: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html

It's likely you'll need to specify other configuration differently. Our documentation breaks down what each of the configuration parameters are: https://docs.inedo.com/docs/installation-linux-docker-guide

Once you get up and running, we'd love to hear you got things set up :)

Cheers,
Alana

Hi @ehsan-bahrami91_9979 ,

This error message is likely related to some sort of proxy server; you can adjust proxy settings under Admin > Proxy.

Cheers,
Alana

Hi @bbrown2_8761 ,

That package should be fine; are you sure it's in your approved-nuget feed?

If you navigate to /feeds/approved-nuget/Selenium.WebDriver.ChromeDriver/103.0.5060.5300 in the Web UI, then you should be able to see and download the package.

When you try to download from the UI, what happens?

Thanks,
Alana

Hi @dward_2542 ,

Thanks for finding the specific package.

The issue is that ProGet does not consider 96.0.4664.1800-beta.2 to be a valid NuGet package version, and gives an error message when trying to access it. See the NuGet Package Versioning documentation to see what's supported.

Most NuGet tools and versions of the NuGet client will not support that version number either.

The easiest way to resolve the issue is to use a newer version of that package.

Cheers,
Alana

Hi @arozanski_1087 ,

Fortunately, sacrificing an albino goat won't be necessary

Simply deleting the package using the UI will suffice to remove it from a feed. Unlisting or running retention rules are not necessary.

I'll share some information to help troubleshoot. Basically, there are three types of packages: Local, Cached, Remote:

1. If it's a Local package, then it will say "Delete Package"
2. If it's a Cached package, then it will say "Delete Cached Package"
3. If it's a Remote package, then there will be no delete option

Remote and Cached packages have the radio-tower icon.

Local and Cached packages are stored on the feed, and even if you remove the connector, cached packages will still be in the feed. This is by design.

Remote packages come from the connector associated with the feed. They cannot be removed (you could Filter then out if you really want). The metadata is not cached (unless you configure that on the Connector), which means that the data is always "live". When you remove all connectors from a feed, there will be no Remote packages.

Based on all this, it sounds like that package is coming from one of your connectors to Mainline. I would just remove the connectors from the feed until you find which one it's in.

Cheers,
Alana

Hi @john-selkirk ,

Another customer has more details on this... it seems that newer versions of dotnet nuget silently ignores publishing symbols unless we have certain metadata in the feed index: https://github.com/NuGet/Home/issues/11871

We may have a fix for this via PG-2154, which is scheduled for July 8's maintenance release. Not sure if it will fix it, but let's hope!

In the meantime, the PUT will work fine though.

Alana

Hi @john-selkirk , hi @alansbraga_8192 ,

If you haven't seen it already, we've done our best to capture how to configure all this:
https://docs.inedo.com/docs/proget-feeds-nuget-symbol-and-source-server

Unfortunately its not as intuitive as we'd like. In general, we recommend doing the "embedded" approach for symbols, to keep things simplified.

The dotnet nuget push command has a few bugs with regards to symbol packages and ignoring the symbol-source argument. Unfortunately this is beyond our control, as it's maintained by Microsoft.

If you run a tool like Fiddler, you can clearly see it's not even trying to PUT the package. Other times it will try to push it to symbols.nuget.org, but silently fail.

nuget.exe seems to be more reliable, but you can also just use curl.exe or PowerShell to PUT the package using the NuGet API

PUT https://proget.local/nuget/feed-name/package

Cheers,
Alana

Hi @Joseph-Saladino_7499 ,

I wasn't able to reproduce the error using the UI, but I could figure out what's causing it and reproduce he error state using the API.

Basically, you have two pipelines named "Standard «redacted» Service Pipeline". One pipeline may be global, one may be part of the application. But in any case, the validation logic is not allowing this to save because it detects a duplicate.

To resolve this, delete one of the pipelines.

Cheers,
Alana

Hi @Joseph-Saladino_7499 ,

Thanks, received! We'll debug/investigate this today or tomorrow.

Cheers,
Alana

Hi @Joseph-Saladino_7499 ,

I think this may be specific to your pipeline data. You should be able to go to the pipeline in "edit view", and share us the JSON document.

You can send that to support at inedo dot com with [QA-874] in the subject (so we can find it) , or also just you open a new ticket. If you do send to support email, please let us know on here that you sent it, since we don't regularly check that email.

thanks,
Alana

Hi @borisov_1556

You say that ProGet doesn't modify files after uploading, only during it. But can ProGet strip and therefore modify packages after uploading in case of triggering re-indexing in a "symbol server" settings?

When you enable any of the "strip" options, ProGet will modify the file during the download process, when it's requested by a client (web browers, nuget.exe, etc). The zip-file is basically rewritten on-the-fly when sending it to the client requesting it. This modified file is not saved to disk or persisted inside of ProGet.

The symbol serving reindexing is unrelated.

do you mean that not only the content of a file, but also the compression type of every file in the .nupkg will be preserved as-is, and ProGet handles that explicitly?

Correct. ProGet effectively just "deletes" the "stripped" files entries from the archive file while it's being streamed. The existing file entries are not modified.

A file entry in a zip archive contains the compression type. So to "change" an entry's compression, you would need to "delete" it from the archive, and then "add" it back to the archive.

So, the point is... something else must be modifying your zip file. ProGet is not. You can verify this by:

1. download file from NuGet.org, check the hash of the file
2. uplaod file to ProGet, check the hash of the file in the package store
3. download file from ProGet, check the hash of the file on disk

MAybe nuget.exe is doing a modifcation? It's really hard to guess, but i would continue the investigation by finding what could be modifying the file.

Cheers,
Alana

Hi @arozanski_1087

The method name is NpmFeeds_SetTagVersion so I think the error you're seeing is about case sensitivity in the method name.