There's nothing jumping out in the logs that's off, it likely is bad information that the client is sending. Most likely it's stemming from the fact that, your package is about 100x as big as a NuGet packages (i.e. .NET libraries) are intended to be. Microsoft will probably never prioritize support for this sort of package, so it's not going to be high on our list either to work-around either. I would recommend you to find a different way of solving whatever problem you are trying to solve in a different way. If you're packaging applications, you should consider a format actually built for such purposes, like the Universal Package Format or Romp packages.

Based on that error, it sounds like ASP.NET 4.5 is not enabled on your server; this is a separate role feature you must install on your computer/server. It could also be a configuration error, as the message suggested, and you've prevented proget's web.config from removing those handlers at the machine level. In this case you'll need to use the built-in web server, or fix the configuration.

Hey Alex, Thanks for the follow up! I did continue working on this, and got to a point where I'm happy with how it is working. I was in contact with Karl about it too via email, and sent him some details, but for reference for others who find it useful.. We went with the solution of putting the config into separate files, using the 'configSource' option as needed to specify references to external files. Further to that, we created an extension for Otter to allow us to manage the settings in those files - similar to how the 'EnsureAppSetting' thing works, but allowing an XPath expression to be used to identify the precise element in the config file to check. That meant we could use it for e.g. files that hold connection strings. (I do intend to publish that extension to the Den at some point - haven't so far gotten around to it though). Let me know if you would like any more detail on what we're doing! Thanks, Andrew

Thank you Alana. We have a lot of feeds configured. Is there an easy way to distinguish which one is/are failing?

The docker image is no longer in Beta, FYI.

Can you provide the full stack trace? It will be logged in Admin > Errors.

These article by AWS will should help provide you details on how to build a connection string to put in there: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_NET.rds.html http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToMicrosoftSQLServerInstance.html

ProGet supports any version of SQL Server starting with 2008.

Hello Bruce, I believe the Jenkins plugin does not want the leading slash on the path, so this should work: parent-folder,myFolder/**/* Let me know if I misunderstood your question - I don't usually work with Jenkins.

Please see KB#1014 - Changing an Inedo Product's URL with the Integrated Web Server

That works - awesome - thank you so much!

In this case, it sounds like the permissions for AWS must not be correct...the user must have full control/read/write access to bucket you specify.

Solved by using link by Martin Helgseen http://inedo.com/support/questions/7217 Thanks

It's hard to say, but if you're not seeing anything come up when you visit the web interface.. it sounds like the web server or IIS isn't running or otherwise configured. The error you shared from the Windows Service would verify this (the service cannot talk to the web application either). Take a look at the Manual Installation Instructions to see if you can identify how things are mis-configured.

In order to create a feed-scoped permission, the task must be feed-scopable. Go to Tasks > Customize Tasks, and remove any attributes that aren't marked "F" for feed scopable. Then you can apply to to feeds.

This should work as you describe if you grant the user "Anonymous" the "View and Download Packages" task for the gems feed.

It's really hard to say; if it works from your browser but not from visual studio, then I recommend to run fiddler, and then see what Visual Studio is doing. Maybe it's a cached password, wrong DNS, or something. If you look at the session logs, you should be able to see how the requests are different.

The error is "The process cannot access the file 'C:\ProgramData\ProGet\Packages.nugetv2\F2\ACME.Shared\ACME.Shared.0.2.19.nupkg' because it is being used by another process." That error is coming from Win32, and will happen when another process tries to lock a file. Most likely, this other process will be an indexing service or anti-virus tool that is scanning/locking the file as soon as proGet starts writing to it.

Use https://registry.bower.io/packages as the connector URL instead of https://bower.herokuapp.com to resolve this. Bower must have changed the default service URL within the past day.

This is only supported in "new" NuGet feeds; some of our preliminary docs are here... https://inedo.com/support/documentation/proget/feed-types/nuget