@itpurchasing_0730 whoops, look like a parameter was missing (-d to set the database name):
docker exec -it inedo-sql /opt/mssql-tools/bin/sqlcmd \
-S localhost -U SA -P '«YourStrong!Passw0rd»' \
-d ProGet -Q '«sql command here»
That should do the trick I hope!
@itpurchasing_0730 you can find that in /reference/api in your instance; that's the Native API
Hello,
The Docker API is supposed to only support based bearer authentication, but in previous versions (v5) it also worked with Basic auth.
There's a sample script on this page that shows how you can authenticate:
https://docs.inedo.com/docs/proget-docker-semantic-versioning
Cheers,
Alana
@kaushal141992_6976 what Network error are you receiving? That's a large file to upload, so it's hard to say where the error is.
IIS has a hard-coded limt of 4gb, but the integrated web server or Docker does not.
Hi Ryan,
If you're unable to login to ProGet as any user, then the issue is cookie-related.
After successfully authenticated on the log-in page, ProGet will send your browser a cookie with an authentication ticket, and redirect to the home page. If you're still "Anonymous" after logging-in, then your browser is not sending ProGet the cookie back.
Make sure you're disabling privacy/cookie blockers.
Cheers,
Alana
Hi @rob-leadbeater_2457 ,
This is a "hard-coded" limit that's built into IIS I'm afraid; if you use the built-in Web Server or Docker, this is not an issue. Another option is to use a drop-path for the packages.
Otherwise, we have not implemented multi-part / chunked upload for Universal Packages yet; it's on our list, but there's not a huge demand for it.
Cheers,
Alana
@msimkin_1572 I believe that the drop folder importer only looks for .nupkg files; so if you just rename it then it should work. The imports should happen within a minute or so, since it monitors pretty frequently
Hi @msimkin_1572 ,
I think that one package is overwriting the other.
Currently, you'll need to either:
In the future (targeting v2023), we plan improve this so you can have a symbol package and a regular package in the same feed.
Hi @jim-borden_4965 ,
Looks like that was a replication glitch on one of our edge nodes 
We didn't enable the right setting (Semantic Tagging) on the Docker Feed on that node. Anyways I just updated it, and the tags now point to where they're supposed to.
Cheers,
Alana
Hello;
I'm really not sure how to reproduce; can you give some step-by-step instructions to get the package files you are trying to import?
Can you try upload them to the feed using the Web UI?
with that, i can try to reproduce.
Thanks,
Hi @22marat22_9029 ,
I assume this is on a ProGet server?
@hwittenborn are you experiencing a similar issue?
Thanks,
Alana
It doesn't look like there's an edit page....
We'd love to learn how you're using manual vulnerabilities -- they don't have a huge use case, in my understanding. Just kind of like a quick/emergency way to block a package.
Can you let us know what workflow is causing you to use manual and then edit manual vulnerabilities vs adding comments to them?
Thanks,
Alana
Thanks @kichikawa_2913 ! We'll add this to our 2023 roadmap review, and we can at least spend sometime reasearching / learning more about it then.
Hi @rmusick_7875 , 2CPU/4GB is pretty lightweight.
What is your configuration? Like how many feeds, what kind of feeds, packages, users do you have? How about connectors to NuGet.org, etc?
Hi @cshipley_6136 ,
Happy to help with this! A couple questions...
Does this apply to all packages you try, or just this one, particular package?
Has this worked in previous versions of ProGet, or is this the first time you're trying it?
Do you get the same error when uploading the tar.gz through the web interface (Feed > Add Package)? If not, what specific commands are you using to upload?
And lastly, can you send us the package files? Then, we will be able to investigate/debug the issue.
For the package files, you can email them to support at inedo com (just include [QA-957] in the subject, so we can find it) - but please let us know if you email, because that box isn't monitored. Or if it's easier for you, please don't hesitate to create a ticket :)
Cheers,
Alana
@sdohle_3924 thanks for letting us know; you're the first person in two years to mention it again, and it's not on our roadmap at this time. Please feel free to share more info about why it would be helpful, how you would use it, etc. It's a pretty big/risky engineering undertaking, we'd want to learn how it will benefit users before considering it further.
Note: we already have a Health Api which makes it easy to check on status, etc.
Hi @markus4830,
It's available, but it's now moved to the Manage Feed page. Did you see ProxyNpmAuditRequestsToNpmOrg documented anywhere? I think that's an old setting name.
Thanks
Hi @jeff-miles_5073 ,
It doesn't look like that field is settable via the API at this time.... unfortunately not everything is.
How are you using that particular API, by the way? Always good to get usecases.
It's probably easy enough to add; let me know if you'd like that (perhaps other things that's missing?)
Cheers,
Alana
Hi @mistique88885_0973 ,
You'll need to add /upload, so basically
curl -k https://proget.domain.local/upack/Feed/upload --user User:Password --upload-file TestUPack.upack
Cheers,
Alana
Hi @scusson_9923,
Did this instance of ProGet work before you changed the connection string? I.e., if you point to a local database, then it works okay?
Or, is this the first time you're trying to use ProGet on this machine?
thanks,
Alana
Hi @inok_spb - that's correct, the proc is dropped/created each time ProGet is upgraded/installed.
Hi @john-a-henson_0753 ,
Without seeing the stack trace it's hard to say, but that error typically is related to a decryption failure of some kind of secret. I'm guessing the API key?.
That most often happens when migrate to a different server, but don't bring over the same encryption key. If you can make sure the encryption key is same, then the error goes away.
Otherwise, you can just delete the vulnerability source and add it back.
Cheers,
Alana
Hi @inok_spb,
That's great news! Thanks for the help and testing - couldn't have fixed this otherwise I think :)
I just committed the code changes on our end (PG-2222), so it should be in the next maintenance release (2022.12).
Cheers,
Alana
Hi @mcascone,
There isn't an API/endpoint for that at this time, but it's easy enough to handle at the consumer/client-level. To tell if something is prerelease, you can just do versionNumber.Contains('-').
In the case of the all versions page, the "client" (i.e. the page) just queries the versions and displays non-prerelease.
Cheers,
Alana
@inok_spb thanks much for investigating this :)
Your assessment makes a lot of sense and definitely isn't easy to figure out.
Let me know if that works; it'll be easy to update our code once we know what works :)
@stijn-peeters-external_8202 Thanks for letting us know; we do have plans to improve this in ProGet 2023, and make it much easier to use.
@jim-borden_4965 glad you got it working :)
On Windows, you can just do an in-place upgrade of MSSQL, and not worry about database migrations. The same is probably true on Docker, and you can just upgrade container.
Anyways safer to back-up.
And if you haven't seen it already, here is the ProGet guidance:
https://docs.inedo.com/docs/installation-backing-up-restoring
It looks like you're following the right steps; here is our HOW-TO guide on the topic:
https://docs.inedo.com/docs/proget-powershell-private-module-repository
If I had to guess, the issue is with HTTPS/TLS resolution. That's what most search results for "Unable to resolve package source" came up with, anyway. You'd have to use a tool like Wireshark to be sure, since the error message from PowerShell isn't very helpful.
You can force PowerShell to use TLS12:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
It might also be certificate related. You may get a better error message if you do like a Invoke-WebRequest to your ProGet URL.
Cheers,
Alana
The easiest approach is this:
Using the drop-path isn't required, and that whole process probably wouldn't take too long.
There are ways to reduce downtime, but that mostly involves using something like "robocopy" or another tool to mirror the package files across servers. The database is relatively small to backup/restore.
Otherwise it sounds like you're on the right track!
Cheers,
Alana
@marc-ledent_9164 after you delete/remove the incompatible extension, do you still see an error with FTP? You may need to restart the service & web application to clear it....
FTP 1.10.1 should work after that.... what message do you see?
The first article refers to migrating a ProGet, including the SQL Server database. The database contains things like users, feeds, and package metadata. When that information is in the database, ProGet will expect the file to be in a specific location on disk, so that's files must be moved.
The second article refers to importing packages into ProGet, and it's effectively uploading new packages.
Thanks,
Alana
@scusson_9923 I'd definitely open a ticket, since it could be unrelated and may require a different back-and-forth w/ screenshots and other sensitive info
But the "View Effective Privileges" tool is the best way way to see what ProGet is using for permissions. There are some other tools available as well we can use to troubleshoot.
Hi @marc-ledent_9164 ,
Did you manually download the extensions? Or, were they prompted for installation?
BuildMaster 7.0 works with only work with Git 1.12.3+. Here is compatibility information:
https://docs.inedo.com/docs/inedosdk-versions-release-notes#product-compatibility
Git 2.1 is built for the Inedo SDK 2.1, which is what BuildMaster 2020 will use :)
Cheers,
Alana
@scusson_9923 in the case of load-balancing, you'd need to do that on each of the nodes, since the "Clear Cache" button only works on the current node
Note: this is meant to be a "once a rare while thing" or for diagnostic purposes so if let us know if that's not the case, and we can try to think up a better solution
@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?
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
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
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:
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