Posts made by atripp

Hi @rosario-digiovanni_1930,

Ah - so it is schema related.

Well, it's definitely compatible with SQL 2019... and we also have no idea why or how that happened. We don't see other users having this issue.

We also tested 00. EnsureDbo.sql works on just about every configuration we could imagine:

• user has no schema
• user has different schema
• user has own schema
• user doesn't have permission to change schema
• etc.

What does SELECT SCHEMA_NAME() return?

Any idea why the following isn't working for you?

IF (SCHEMA_NAME() <> 'dbo') BEGIN
   DECLARE @SQL NVARCHAR(MAX) = 'ALTER USER [' + CURRENT_USER + '] WITH DEFAULT_SCHEMA = [dbo]'
   PRINT 'Changing default schema ("' + SCHEMA_NAME() + '") to dbo via: ' + @SQL
   EXEC sp_executesql @SQL
   PRINT 'Schema changed.'
END

FYI, here is Microsoft's docs on SCHEMA_NAME:
https://learn.microsoft.com/en-us/sql/t-sql/functions/schema-name-transact-sql

Hi @rosario-digiovanni_1930 ,

Thanks for sharing the details; from here, I would recommend just working with inedosql.exe and the SqlSCripts.zip file that's in the ProGet.SqlScripts-22.0.17 package. You can just run inedosql update after extracting the SQLScripts.zip file

The error is from from a while ago (14.07.2020 14:41:44), so I guess it's nothing to worry about. Perhaps it's the same underlying issue?

There's definitely something wrong... I just have no idea what it is. The only guess is schema/permissions, but you've already checked it.

I will describe to you what's happening, and hopefully you can troubleshoot with your database team better, especially since you'll have all the scripts that are run...

The script 0.1.AddStoredProcInfo.sql does the following:

• drop/create table __StoredProcInfo
• drop/create stored procedure __AddStoredProcInfo
• drop/create stored procedure __GetStoredProcInfo
• execute __AddStoredProcInfo

Then later, the 1.ApiKeys_CreateOrUpdateApiKey.sql script is executed. This script starts by executing __AddStoredProcInfo again, but it's called with the [dbo].[__AddStoredProcInfo] prefix instead.

So I think the issue is schema-related.

But as I mention, we try to mitigate this earlier with 00. EnsureDbo.sql . This script works like so:

IF (SCHEMA_NAME() <> 'dbo') BEGIN
   DECLARE @SQL NVARCHAR(MAX) = 'ALTER USER [' + CURRENT_USER + '] WITH DEFAULT_SCHEMA = [dbo]'
   PRINT 'Changing default schema ("' + SCHEMA_NAME() + '") to dbo via: ' + @SQL
   EXEC sp_executesql @SQL
   PRINT 'Schema changed.'
END

Anyway, please let us know what you find. We'd love to make these scripts work in more scenarios, and not cause problems like this.

Hi @jeff-peirson_4344,

I don't think there's been any changes to the Asset Directory in v2022 that would have caused anything like this.

Do you have a full stack trace of that message? It sounds like an operating system error, and if that's the case - it wouldn't make a lot of sense that the same action works from the Web UI, since it's the same code. So that might mean it's probably unrelated to ProGet, and some weird environmental thing.

It could also be an "error handling an error" that yields an incorrect message, but we'd want to see the full stack trace for that.

Cheers,
Alana

Hi @rosario-digiovanni_1930 ,

Unfortunately, it looks like there's strange "corruption" with your database. Objects that should exist don't seem to exist.

For example, __AddStoredProcInfo is a stored procedure that's dropped/created early on in the update process. You should see something like INFO: Executing untracked script OBJECTS/4.PROCEDURES/0.1.AddStoredProcInfo.sql..., above all the other items.

PackageVersions is a table that's created in v2022., before running all the stored procedure creation scripts. That is a very simple CREATE TABLE script, so I can't imagine how it failed.

Any ideas? Is there some strangeness with with DB Schemas or anything? The installer should crash if your user isn't part of the dbo schema, but we've also seen that detection fail because of schema aliasing configuration on the server. That's a very rare, obscure setting.

Did you have past failed installations? You can use the inedosql tool to find out what errors exist in the database: https://github.com/Inedo/inedosql#errors

You can find an inedosql.exe within the Manual Install Files for your version:: https://my.inedo.com/downloads/installers

Hi @rob-leadbeater_2457 ,

It sounds like you'll need to grant yourself (UserB) "sysadmin" access. You should probably also grant the local Administrators group access as well while you're at it :)

The easiest way to do this is with the SQL Server management tools, since it's all gui-driven. That's a free download/install from Microsoft, and I would recommend installing it on the server anyways. But it's also possible to do it with the command line/scripts.

Microsoft has some guidance on how to do this;
https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/connect-to-sql-server-when-system-administrators-are-locked-out?view=sql-server-ver16

Once you've given yourself sysadmin, you should have no issues.

Alana

Hi @k-gosciniak_5741 ,

We plan to implement that in ProGet 2023 - it requires a major change, so we won't be able to do it in a maintenance release.

There is no release date for ProGet 2023 yet, but please check in the coming months :)

It will most certainly happen in the firs half of the year, as we already started planning/development.

Cheers,
Alana

Hi @pmsensi ,

That is the general process you'll want to use... basically just assign the licenses as you need them. In general, as part of a package approval workflow:
https://blog.inedo.com/nuget/package-approval-workflow

There are over 300k packages on nuget.org (5M+ versions), and growing. So it's many packages. ProGet does not download a list these packages, but displays live data from the NuGet.org feed.

hopefully that helps :)

Cheers,
Alana

Hi @pmsensi ,

Yes, you can set up this as a licensing rule - to block packages with unknown licenses.

Reporting & SCA > Licenses > manage license types > Manage Default License Rules

:)

Cheers,
Alana

Hi @pmsensi ,

Oh I see! In this case, I think your "Feed Usage" setting is currently set to "Private". You should set this to "Public" packages- then the licensing will be displayed/configurable.

Alana

Hi Pedro,

There are multiple ways that an author can specify a license on a NuGet package:
https://blog.inedo.com/nuget/nuget-license-expressions

Or, a package author can specify no license at all. If the author chooses "file" as the license type, then ProGet will only be able to "see" this license if the package is in ProGet - either as a Cached or Local package.

For example, the SmartInspect package has a file" type of license agreement:

So in this case, you want to read the "embedded license file", then assign a license agreement code to it.

Note that, if a package file has not been downloaded yet, then it will appear to Proget as having no license at all. This is a NuGet API limitation.

Cheers,
Alana

Hi @jimthomas1_7698 ,

What should target #0 be? (Deployment Target currently says 'Build to localhost', is that what target #0 refers to?)

This message could definitely be clarified; but it basically means that Deployment Target isn't set for the first stage. If you see "Build to localhost" on the pipeline overview page, I'm guessing you didn't "Commit" the changes (save) -- it's at the top of the page. You have to explicitly save the pipeline that you're editing.

Where in the Publish command do I specify the Resource Group, Resource Name and Subscription? Or will BuildMaster pull those azurewebsite publish parameters from the project's Properties/PublishProfiles .pubxml file?

I'm not familiar enough with azurewebsite publish to be honest... but under the hood, the DotNet::Publish operation calls to dotnet publish. So if your project is configured to use the PublishProfiles... then maybe it will work?

You can pass additional arguments into DotNet::Publish (which will get directly passed to dotnet publish, using the AdditionalArguments parameter)

FYI: Deploying to Azure Websites is a Deployment Script Template we intend to create later. It's unfortunately a little complicated to do, since it primarily reles on a

Which, if any, of the documentation can I rely on for help?

We put that "Documentation Renovation in Progress" warning on the pages that are outdated; there's not too many of them with that warning... and we're making our way through them one page at a time

In any case, don't hesitate to ask questions - it is often an opportunity for us to improve our software or documentation.

Hi @kenneth-garza_2882 ,

That should be the case, under the hood, ProGet is using this API:
https://learn.microsoft.com/en-us/windows/win32/fileio/creating-and-using-a-temporary-file

According to the docs for GetTempPath, the first path found will be used:

1. The path specified by the TMP environment variable.
2. The path specified by the TEMP environment variable.
3. The path specified by the USERPROFILE environment variable.
4. The Windows directory.

So it seems there's many way to specify this.

Hi @kenneth-garza_2882 ,

ProGet uses temp files for a number of things, including buffering uploads like this.

This shouldn't cause any space problems, as ProGet will delete these files upon successful use, and Windows can automatically cleanup files that failed to upload. Relatively speaking it's a small amount of temporary space compared to everything else in there.

If you're worried about using a system drive for temporary files, you can change the App Pool User's Profile path, or just the temporary path:
https://www.howtogeek.com/285710/how-to-move-windows-temporary-folders-to-another-drive/

Cheers,
Alana

Hi @philipp-jenni_7195 ,

I'm afraid I can't reproduce this, and we've reviewed this code already. Only packages the exist will require Feeds_OverwritePackage privilege.

If you can provide me with step-by-step guide using a New Feed and a package file to use, I will try your steps.

The steps should basically be

1. Create New Feed named XXX
2. Upload this file to the feed

Cheers,
Alana

Hi @philipp-jenni_7195,

We have seen a few edge cases that will cause this behavior:

• if the package version is "unlisted"
• if the package file already exists on disk, but no database record exists

In this case, if you should be able to upload the package from the UI, then delete it, then it should work again.

Cheers,
Alana

@itpurchasing_0730 there is; see Advanced > Web.HideHomePageFromAnonymousUser

Hi @p-pawlowski_8446 ,

I'm sorry but I'm not totally sure what you're asking; we're not familiar with JumpCloud.

Are you looking for how to publish a Chocolatey Package? We have a step-by-step on how to create a priate choco repository, but not on creating packages...

https://docs.inedo.com/docs/proget-howto-private-chocolatey-repository

@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:

• embed the symbol files in your nuget package (easiest)
• -or -
• create two feeds, one for packages, the other for symbols

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

Hi @joacim-svensson_8194 ,

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

Hi @curtis-denotter_1361 ,

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

Hi @itinfrastructure_7135 ,

The easiest approach is this:

1. Notify users of downtime
2. Shutdown old server
3. Migrate database, files
4. Start the new server
5. Edit DNS to the new server

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?

Hi @itinfrastructure_7135 ,

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.