How do I resolve a "CLR20r3" error during ProGet 3.6.1 installation?

I am attempting to upgrade ProGet from 3.5.1 to 3.6.1.

I can run the installer and see that it appears to unpack something, but then I get the following error and the installer crashes before the upgrade takes place:

Problem signature:
  Problem Event Name:	CLR20r3
  Problem Signature 01:	ProGet.Setup.exe
  Problem Signature 02:	3.6.1.1
  Problem Signature 03:	555110df
  Problem Signature 04:	System.Data
  Problem Signature 05:	4.0.30319.34209
  Problem Signature 06:	5348a63a
  Problem Signature 07:	25bd
  Problem Signature 08:	27
  Problem Signature 09:	System.Data.SqlClient.Sql
  OS Version:	6.3.9600.2.0.0.272.7
  Locale ID:	1033
  Additional Information 1:	1430
  Additional Information 2:	14307b8a93f6b855c1b3ae885ca3884b
  Additional Information 3:	83c6
  Additional Information 4:	83c624f4be2a08287a8909b0ca48841b

The web site is on Windows Server 2012 R2. My ProGet database is on a different machine running SQL Server 2012 (11.0.5548.0).

Product: ProGet
Version: 3.6.1

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.

The problem ended up being that I downloaded the default installer - ProGetSetup3.6.1_SQLExpress.exe - and it was failing on the SQL Express unpack.

After visiting the other versions page and getting the one without SQL Express - ProGetSetup3.6.1.exe - and electing not to automatically back up the database, I had a successful install.

It might be a good idea to enhance the installer that comes with SQL Express to be smart enough to detect an existing database connection and bypass anything to do with SQL Express.

Same Problem here - same solution here ;-)...

This is strange; there is no difference in the installer that includes SQL express vs the installer that doesn't. The only logical difference is during new installs, not upgrades, and even then it only checks for the presence of the SQL installer file on disk to determine whether to enable/disable the option to use the bundled SQL server.

You will almost certainly get some kind of error trying to do a database backup from the installer when SQL is installed on a different machine, regardless of which installer you are using, since the path specified for the backup file will be on the SQL server, and so the directory must exist there and be accessible to the user account running SQL, which normally is not the case.

Regardless, it is a good idea to use the installer that doesn't include SQL for upgrades just because it's a smaller download.

In my case SQL is on the same machine (default installation), so that couldn't be the cause for me...

Just making sure I understand the problem- upgrade works if you do not do a database backup, but crashes if you do. Is that correct?

No, I didn't even got that far...
The Setup crashed right at the beginning, but the installer without SQL worked fine.

Running ProGetSetup3.6.1_SQLExpress.exe on the web server instantly crashed with the CLR20r3 error. I hypothesize from the name of the error that it could be that I don't have .NET 2 installed on that machine - it is a Server 2012 R2 box. Again, the SQL database is on a different box for me. I did not install .NET 2 on the box to test that hypothesis.

Running ProGetSetup3.6.1.exe got me past the initial "double-click" to run the installer, but if I left the "back up the database" box checked, the backup would fail (I think due to credentials) and the installer would stop.

Running ProGetSetup3.6.1.exe and unchecking the option to back up the database yielded success.

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!