Unfortunately there's not enough information provided for us to provide any assistance. I'm not sure what feed/package type this is (NuGet, npm, etc), what version you upgraded from, how you're trying to use ProGet, what specific errors you're receiving, etc.

I bumped into this issue as well. It turns out if you wanna use existing local SQL server, you need to add an account "NT AUTHORITY\NETWORK SERVICE" to your SQL database. To be clear, this account is added to ProGet database during installation but it didn't mark as "Public" in server role.

You do have to check the "remove the database and packages" options in the uninstaller, so if you did that it should have done just that, unless some error occurred or something like that. It's hard to say why things weren't removed in this case, but it's hopefully easy enough to manually remove if it didn't work. We'd rather there be a bug in not removing, instead of a bug in removing when you didn't want it to :)

Thanks Alana, I will have to run the install as a service account to make sure it has access to SQL. I didn't expect it connects to SQL server as it unpacks the resources. So, it didn't cross my mind that this would be an issue. I have not yet validated if the issue is resolved, but I am 99% sure it will be. I will reply to the post once I confirm it.

To migrate ProGet to a new server is as follows: If you're using a local database, back it up and restore it on the new server If you're using a local package store, copy those to the new server (ideally same exact path) Install the same version of ProGet on the new server, pointing to the new database Change whatever IIS settings you desire From the web app, edit whatever settings may have changed from the Admin section

Yes, but note ProGet is licensed for each server it's installed on, so if you keep both servers active, then you'll need an additional license.

if you specify the /LogFile=[filename] argument, then the install log will be written there.

We made and tested several changes to the installer a while back, but it's not something we regularly test/verify. Please share what you find work! Thanks.

We don't have a built-in mechanism to do that just yet

The INEDOPROGETSVC service is used by ProGet to perform background tasks (indexing, cleanup, etc) and is required to run ProGet. The only options (right now anyway) to install the ProGet web application are: IIS-hosted Integrated web server (this is essentially a 2nd Windows service) Linux via Docker (currently v4.0 in beta)

To find the connector, go to Admin gear > Manage Feeds > Edit Feed (pencil icon), and that will have the list of connectors. For the error itself, try some of these recommendations: http://stackoverflow.com/a/703285

Thanks; we've identified a possible race condition during initialization, specifically involving discovering the connection string of the currently installed instance. We've made a small code change which should resolve this issue - assuming it is the cause. We haven't been able to reproduce it on our systems. The installer for the next version (which should be 3.6.2) will have the fix, so you may want to try using the larger installer again just to see if the issue goes away. You never need the full installer to perform an upgrade, however.

Thanks for the help investigating this. We've identified a possible race condition during initialization, specifically involving discovering the connection string of the currently installed instance. The presence of .NET 2 shouldn't affect things, as the installer specifically targets 4. The 20 in the CLR20 error just refers to the runtime version. .NET 4 runs on the CLR 2.0 runtime, confusingly enough. We've made a small code change which should resolve this issue - assuming it is the cause. We haven't been able to reproduce it on our systems. The installer for the next version (which should be 3.6.2) will have the fix, so you may want to try using the larger installer again just to see if the issue goes away. You never need the full installer to perform an upgrade, however. Again, thanks for the help!

This error means that the connection string in the installed product doesn't work for the user installing the software. Most likely, you don't have access to the database or server. I think the discussion here http://inedo.com/support/questions/3126 may be related as well.

i will try to submit this to avira. maybe it would be nice to report it to them too since it is your product that gets blocked! this could lead to misunderstandings.

The installed express database by default is at localhost\PROGET (i.e. machine_name\instance_name). To switch, simply backup and restore the database into the new instance, and update the connection string in web_appSettings.config under the web installation path, and ProGet.Service.exe.config under the service install path.

Glad to hear it! Thanks for letting us know.

Of course, it really depends on the size of the server. ~80% of in-house usage comes from requesting known package (id+version), so this is a fairly performant operation and doesn't take much searching. So, one or two servers is usually ok. For very large package stores (100k+), we seem to have hit some interesting file system / FileWatcher limitations; it works, but sometimes the indexer just stops working. We do plan to redesign the package store, but the work around is easy (just restart the indexing service) Please see http://inedo.com/support/kb/1073/load-balanced-and-high-availability-installation-of-proget for more information on LA/HA proget.

Got there in the end. Turns out that the proget service wasn't correctly configured. Once I changed this and restarted the service the packages turned up!

Thank you. I have replaced the contents of the WebApp and Service folders with the contents of the 3.1.0 manual installation zip file (except the config files of course). This seems to work as well. I think it is more or less the same effect as what you did by uninstalling and reinstalling, although your method is probably a bit safer! Luckily the database schema doesn't seem to have any updates in 3.1.1 that means it doesn't work with 3.1.0.