Posts made by jw

The NuGet package is created on disk, so this shouldn't be a permission problem. The matching .snupkg produces errors and is subsequently missing on disk and also not indexed.
API key is configured for both the package as well as the symbol source URLs.
.snupkg support is enabled on feed.

nuget.exe output:

D:\test>nuget push -Source https://192.168.x.x/nuget/nuget-hosted/v3/index.json SourceLinkTestLib.2.0.6.nupkg
Pushing SourceLinkTestLib.2.0.6.nupkg to 'https://192.168.x.x/nuget/nuget-hosted/package'...
  PUT https://192.168.x.x/nuget/nuget-hosted/package/
  Created https://192.168.x.x/nuget/nuget-hosted/package/ 231ms
Your package was pushed.
Pushing SourceLinkTestLib.2.0.6.snupkg to 'https://192.168.x.x/nuget/nuget-hosted/symbolpackage'...
  PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
  InternalServerError https://192.168.x.x/nuget/nuget-hosted/symbolpackage/ 67ms
  PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
  InternalServerError https://192.168.x.x/nuget/nuget-hosted/symbolpackage/ 7ms
  PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
  InternalServerError https://192.168.x.x/nuget/nuget-hosted/symbolpackage/ 56ms
Response status code does not indicate success: 500 (Internal Server Error).

Server log:

System.IO.FileNotFoundException: Could not find file 'C:\ProgramData\ProGet\Packages\.nugetv2\F1\SourceLinkTestLib\SourceLinkTestLib.2.0.6.snupkg'.
File name: 'C:\ProgramData\ProGet\Packages\.nugetv2\F1\SourceLinkTestLib\SourceLinkTestLib.2.0.6.snupkg'
at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategyCore(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategy(FileStream fileStream, String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at Inedo.IO.FileEx.Open(String fileName, FileMode fileMode, FileAccess fileAccess, FileShare fileShare, FileOptions fileOptions)
at Inedo.ProGet.Extensions.FileSystems.DirectoryFileSystem.OpenReadAsync(String fileName, FileAccessHints hints, CancellationToken cancellationToken)
at Inedo.ProGet.Feeds.NuGet.NuGetFeed.InstallOrUpdateSnupkgAsync(Stream stream, Nullable`1 publishDate)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.PutHandler.ProcessPutRequestAsync(AhHttpContext context, WebApiContext apiContext, RequestData urlData, NuGetFeed feed)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetFeedHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(AhHttpContext context)

@atripp

Thanks for the update, looking forward to the release.

@stevedennis

Is there any news on this subject by any chance?

There is updated documentation with step-by-step instructions here:

https://docs.inedo.com/docs/installation-windows-https-support#configuring-https-on-the-integrated-web-server

@atripp

Thanks for the query, this has indeed fixed the 2nd issue and pushing packages now works without error.

About the 1st issue. Since the source code for nuget.exe is public, one could try to debug this directly in the client, to see what the expectations from a server are.

Hi,

since we're highly interested in this feature, I spend some time trying it out, but ran into two issues.

1. According to this post on GitHub from a Microsoft employee, when pushing packages with nuget.exe using an API key, it should pickup and reuse this key also for the symbol package.

When only having an API key set for the package feed itself, I get a password prompt for the symbol package.

Pushing SourceLinkTestLib.2.0.0.nupkg to 'https://192.168.x.x/nuget/nuget-hosted/package'...
  PUT https://192.168.x.x/nuget/nuget-hosted/package/
  Created https://192.168.x.x/nuget/nuget-hosted/package/ 54ms
Your package was pushed.
Pushing SourceLinkTestLib.2.0.0.snupkg to 'https://192.168.x.x/nuget/nuget-hosted/symbolpackage'...
  PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
MSBuild auto-detection: using msbuild version '17.4.1.60106' from 'C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin'.
Please provide credentials for: https://192.168.x.x/nuget/nuget-hosted/v3/index.json
UserName:

When also setting an API key for the */symbolpackage URL, this prompt goes away. But according to the Microsoft guy, this should not really be required.

2. When fixing the issue decribed in 1., pushing the .snupkg returns an error, the package itself seems to be actually copied to the ProGet package directory on disk.

Log message:

An error occurred processing a PUT request to https://192.168.x.x/nuget/nuget-hosted/symbolpackage/: The EXECUTE permission was denied on the object 'IndexedSymbolEntry', database 'ProGet', schema 'dbo'.

Details:

Microsoft.Data.SqlClient.SqlException (0x80131904): The EXECUTE permission was denied on the object 'IndexedSymbolEntry', database 'ProGet', schema 'dbo'.
at Microsoft.Data.SqlClient.SqlCommand.<>c.<ExecuteDbDataReaderAsync>b__207_0(Task`1 result)
at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
at Inedo.Data.DatabaseContext.DbResult.CreateAsync(DbCommand command, DatabaseContext context, DateTimeOffset startTime, Stopwatch stopwatch)
at Inedo.Data.DatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.Data.SqlServerDatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.Data.DatabaseContext.ExecuteNonQueryAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.ProGet.Feeds.NuGet.NuGetFeed.InstallOrUpdateSnupkgAsync(Stream stream, Nullable`1 publishDate)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.PutHandler.ProcessPutRequestAsync(HttpContext context, WebApiContext apiContext, RequestData urlData, NuGetFeed feed)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.ProcessRequestAsync(HttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetFeedHandler.ProcessRequestAsync(HttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(HttpContext context)
ClientConnectionId:ab40b37a-98dc-4cf4-be5d-7ff3ed663d8f
Error Number:229,State:5,Class:14

You're right, caching SourceLink enabled PDBs would be somewhat useless for outages.

Though there are still plenty of "old-school" PDBs around, especially for native code (C/C++).

I've looked at the Event log, but it is pretty inconvenient, since one has to click through all the events to find out which package the log entry is actually about.

It would be nice if my two points from above could make it into v2023.

This together with the support for .snupkg would probably allow us to migrate from Nexus.

Pretty much for the same reason to cache NuGet packages from nuget.org.

• Performance in the local network
• Being able to continue working during internet outages or when "the cloud" decides to take a break
• Having a backup of a 3rd party resource one does not control

Ok, thanks for the information.

Thanks for considering!

For my specific use case an URL to the package would already be sufficient. Could that be made available easier? The code that executes these hooks already must have some context of the package (Id, Version, etc.)?

I changed the log level to "Everything" but nothing shows up in the logs at all ("There are no API request logs."), pretty odd..

I'm also fairly certain that the key itself is working properly, because when I comment it out in my nuget.config I get a login prompt from nuget.exe when trying to push.

@sebastian

My permissions look like this:

I'm pushing with the api key of the greyed out user who has admin rights.

I also tried removing the Anonymous rights here entirely, but no change as expected, since these are just viewing rights.

I saw this has been implemented a while ago, so thank you for that.

Some feedback:

HTTPS Binding to a Hostname

Essentially worked like a charm.

Maybe a minor thing for the documentation that could help people in the future:

I opened the certificate and blindly copied the first thing that looked like a thumbprint hash (Yea I know, reading is hard...). But in case of windows that is the Serial number and not the thumbprint, which of course totally won't work.

So a little hint the documentation could be helpful, e.g.

cerhash is the thumbprint of you SSL certificate
=>
cerhash is the thumbprint of you SSL certificate NOT the serial number

HTTPS Binding to a Port (Experimental)

Also worked nicely, here also just a minor documentation nitpick:

In the line
"For example, if you wanted to bind to port 4403 for NETWORK SERVICE, you'd run this command:"

The port is probably a typo? At leas the next lines say something different.

Also first it says
netsh http add urlacl url=https://*:443/ user="NETWORK SERVICE"

but then a few lines down it says

<WebServer Enabled="true" Urls="https://*:8625;http://*:8624" />

A couple lines down the 2nd line shows up again and even further down it shows up again with yet different ports.

For this configuration to work properly these settings must match up.

Hi,

we're currently looking to migrate away from Nexus and one feature that is missing is a proxy server for symbols.

https://github.com/sonatype-nexus-community/nexus-repository-microsoft-symbol-server

The proxy should essentially behave similar to a NuGet caching proxy for nuget.org, but instead for the Microsoft and the NuGet symbol servers.

Can this be done somehow or are there plans to support this?

Hi,

is there a variable that contains either the base url to the webinterface or the full url to a package that can be used in webhooks?

I've created a message card with a clickable link like shown below. The only thing that I currently have to hardcode is the base url to the ProGet webinterface.

Is there a better way to do this?

{
    "@type": "MessageCard",
    "@context": "http://schema.org/extensions",
	  "title": "$FeedType $PackageId $PackageVersion was $WebhookEvent",
    "summary": "summary",
    "sections": [{
        "facts": [{
            "name": "User:",
            "value": "$UserName"
        }, {
            "name": "Link:",
            "value": "[$PackageId $PackageVersion](http://192.168.0.1:8624/feeds/$FeedName/$PackageId/$PackageVersion)"
        }, {
            "name": "Feed:",
            "value": "$FeedName"
        }],
        "markdown": true
    }]
}

Hi,

two issues with user tracking for NuGet uploads

1. I can't find a way to see which user uploaded the package. Both on the metadata and the history page the upload time is shown, but not who uploaded it.
   Is there a way to show this?

2. When uploading a NuGet package via ApiKey it seems like ProGet does not identify the user correctly. I've set up a Team notification hook for testing and the user is only shown when uploading via website. When pushing the package via nuget.exe the user is only shown as "Anonymous".
   How can this user recognition be enabled for uploads via API?

Hi,

is there a way to be actively notified when a new ProGet version was released?

Some sort of newsletter one can subscribe to?

I know that the webinterface will show something, but I'm looking for something less passive.

Hi,

is there a way to activate a "Remember me" functionality in ProGet?

An example from GitLab:

The basic idea is for the session cookie to be valid for a (ideally configurable) amount of time, so one doesn't have to log in over and over again when closing and reopening the browser.

@lm FYI, our plan is to create a second URL for pushing symbol packages, and then essentially save the files pushed to that URL as .snupkg, next to the .nupkg files on disk. This URL will be wired to SymbolPackagePublish and documented.

Do you mean like a second URL for a single feed? Would the .snupkg then also show up in the feeds search results?

I think it would be good to at least have an option to hide them from the regular package list. Also deleting them together would probably also make sense.

You're correct -- that would probably work, but we thought a "single feed approach" would be much better from a user-experience standpoint. This way, there's just one feed to configure, and you push package files and/or symbol files to that feed using that default NuGet configuration. The files will be are stored on disk, right next to each other.

True, though there are also a few downsides worth mentioning. Signatures don't work anymore and the package itself is always different (Size, file hash) to what a build server might spit out, making protentional issues in the pipeline harder to spot. Once the SymbolPackagePublish resource is implemented there really is no downside for the user anymore, a single nuget push command will do.
Also another pleasant side effect to this is, that it would now be possible to manually push .snupkg to a ProGet feed with nuget.exe, because even in this case the client is checking for this resource on server side before doing anything.

This is something we're planning for ProGet 2023, but can probably do as a preview feature in December or January.

That is good to hear, thanks.

In PG-2154 there is a comment "Update: this was not trivial and we will take a new approach."

Is there any update for this?

I did a quick an dirty test and to me it seemed rather easy to get it to work. I create two ProGet feeds, then downloaded the index.json from the first feed, added the SymbolPackagePublish resource to the json and pointed it to the second feed. That file was then copied on a webserver. Using its URL as a -Source for nuget.exe or putting it as defaultPushSource in the nuget.config immediately solved the problem.

If I'm not completely wrong, all that is needed is a configuration option at the first feed "Use Feed x as symbol feed" and as soon as that is configured, the index.json of the first feed can return the correct SymbolPackagePublish resource and everything should just work.

Sounds like a plan.

Looking forward to trying it out.

Obviously it's pretty easy to just wire up values (and we'd be happy to do that), but my only hesitation is documentation and cross-platform compatibility.

Cross-platform should not be an issue, since this is one of the reasons Microsoft created Kestrel in the first place. Of course the Windows cert store part of the configuration does not make sense in a Linux context, but that should be pretty much the only limitation.

Brainstorming a bit but... from the UI, we will just support one URL I think. I don't know why you'd want multiple...

From what I understand at least two URLs are needed to support HTTP and HTTPS side by side, but that could be abstracted away by the UI.

The docs you linked from Microsoft are confusing, and it's not really clear what fields to use or why. I guess, in general, you'd select a file (which InedoHub would generate?) or the cert store (that's Windows only, right?).

There are basically four sections that are of interest:

"Http" => Plain HTTP (Similar to Urls but just one host per endpoint)
"HttpsInlineCertFile" => PFX file based (Most likely be used by Windows users that don't want to deal with the cert store)
"HttpsInlineCertAndKeyFile" => .crt+pem file based (Most likely used by Linux users)
"HttpsInlineCertStore" => Windows cert store integration, only works on Windows.

I think the other parts can be ignored.

And I guess what, when you generate a cert yourself, it's a pfx or something? I always forget the differences....

PFX is just one possible certificate format, it is possible to generate all types of self-signed certificates. I believe the majority of business/enterprise users will probably use a cert they get from their IT department from the company-wide PKI and then they just need different options to plug that into ProGet.
Letting the user installing ProGet generate a certificate can be done, but it will show up as insecure (red, broken lock, etc.) in all browsers and also package managers will probably complain about it being untrusted. So I'm not 100% sure that implementing this time well spent, since there are a million guides on the internet how to generate a cert.

How would you suggest we modify that element to support the different options they have?

I would probably switch from the Urls parameter to a list of endpoints. This way the HTTP+HTTPS scenario can be supported as well as the the 4 options above.
The JSON from the example could simply be translated to XML 1:1.

<WebServer Enabled="true/false">
  <Kestrel>
    <Endpoint>
      <HttpsInlineCertStore>
        <Url>https://192.168.0.1:443</Url>
        <Certificate>
          <Subject>my.company.domain.local</Subject>
          <Store>My</Store>
          <Location>LocalMachine</Location
          <AllowInvalid>false</AllowInvalid>
        </Certificate>
      </HttpsInlineCertStore>
    </Endpoint>
  </Kestrel>
</WebServer>

It should be possible, using the Microsoft.Extensions.Configuration.Xml, to read the config file into an IConfiguration object and feed the relevant portion into Kestrel, this is pretty much what we currently do. This way we don't have to reinvent the wheel with HTTPS configuration and can offer all the flexibility that Kestrel offers right out of the box.

new HostBuilder()
            .ConfigureWebHostDefaults(webBuilder => webBuilder
                .UseConfiguration(configuration)
                .UseKestrel((context, serverOptions) =>
                {
                    serverOptions.Configure(context.Configuration.GetSection("Kestrel"));
                })

We are also interested in this support, since we really don't want to go down the IIS route.

Yes. Not exactly sure how yet, but we would like the integrated webserver to support this as easily as possible.

From what I can tell ProGet seems to be an ASP.NET Core 6.0 application and the underlying (internal) webserver is probably Kestrel. We faced a similar requirement with our own product running the same stack.

A first easy way to support this would be to expose more of the relevant Kestrel config: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/endpoints?view=aspnetcore-6.0#replace-the-default-certificate-from-configuration-1

We are particularly interested in the HttpsInlineCertStore option, to be able to use certificates directly from the Windows cert store.

So maybe extending the ProGet.config with the relevant parts could be a good first step, before any more fancy features like UI integration or self-signed cert generation are implemented.

<InedoAppConfig>
  <WebServer Enabled="true" Urls="http://*:8624/">
     <endpoint config goes here />
  </WebServer>
</InedoAppConfig>