3

I have a solution containing 4 projects.

  • One .NET Framework project (Ananas)
  • Two .NET Core project (Bananas & Cherries)
  • One Xamarin project (Dewberries)

Every time I start Visual Studio 2017 Community (15.6.2) and load the solution, it hangs itself while loading in the first project (Ananas).

screenshot

I can sit and wait for it to load for 30 minutes or more, but the progress bar will just keep animating. I have to totally kill Visual Studio to stop this.

If I then delete the solution folder, and unpack it anew from a backup archive that I have stashed away and load it up again, it loads the first time without hanging. But when I close the solution, close Visual Studio, restart and load it again, it starts to hang again.

Samir
  • 1,213
  • 1
  • 15
  • 27

4 Answers4

3

I had the same problem and removing of the hidden .vs folder in solution directory fixed the problem.

Koray Elbek
  • 794
  • 5
  • 13
0

Try opening Visual Studio in Administrator Mode.

Aron
  • 3,419
  • 3
  • 30
  • 42
Nivas Pandian
  • 416
  • 1
  • 7
  • 17
0

There are lots of different guids in the Visual Studio solution files.

As per my comment to @samirg's answer:

The first Guid Project("{ <GUID> }") is the .net project type, the second Guid ".csproj", "{ <GUID> }" is the unique project identifier. You should not change the first, but you can set the second to a unique ID.

Visual studio generates both, the first from the project type you select when creating a new project, the second uniquely identifies that project.

It appears you have a mix of both new and old project guids as seen here in the .net Project System repo README.md

https://github.com/dotnet/project-system/blob/master/docs/opening-with-new-project-system.md

The project type guid (at this point now that there are 2 for each language) tells Visual Studio to treat the project like an old or new project type.

FAE04EC0-301F-11D3-BF4B-00C04F79EFBC is the old C# project guid.

9A19103F-16F7-4668-BE54-9A1E7A4F7556 is the new C# project guid.

Since you have a mix of both I would change all of the old guids to the new ones for consistency in the behavior of the solution.

The new VS2017 project system has a bunch of benefits.

seangwright
  • 17,245
  • 6
  • 42
  • 54
-1

If you inspect the Solution (SLN) file, you may find duplicate GUIDs for two or more of the projects. See the example below.

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Ananas", "Ananas\Ananas.csproj", "{F16C0F09-8509-4370-B4FF-C6E1C1C27C31}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Bananas", "Bananas\Bananas.csproj", "{9D7771AE-8A04-438E-858A-7DBD42025BF4}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Cherries", "Cherries\Cherries.csproj", "{91FB0CB7-5DC1-4B86-B33C-F22BE6A11CF2}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Dewberries", "Dewberries\Dewberries.csproj", "{424ABA82-B745-4376-8A52-632B9016608E}"
EndProject

As you can see the first and the last project have the same GUID, and the two projects in the middle have the same GUID as well. What you need to do is generate a valid GUID to differentiate the conflicting projects. Such that, you get something like the following.

Project("{2CD1389C-9B3D-41E9-9AC4-FB6402671C81}") = "Ananas", "Ananas\Ananas.csproj", "{F16C0F09-8509-4370-B4FF-C6E1C1C27C31}"
EndProject
Project("{73ED998E-CD14-48E9-8193-A60F496F9CD7}") = "Bananas", "Bananas\Bananas.csproj", "{9D7771AE-8A04-438E-858A-7DBD42025BF4}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Cherries", "Cherries\Cherries.csproj", "{91FB0CB7-5DC1-4B86-B33C-F22BE6A11CF2}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Dewberries", "Dewberries\Dewberries.csproj", "{424ABA82-B745-4376-8A52-632B9016608E}"
EndProject

To generate valid GUIDs, I suggest that you use an online tool for this, such as Online GUID Generator.

Samir
  • 1,213
  • 1
  • 15
  • 27
  • The first Guid (`Project("{ }")`) is the .net project type, the second Guid (`".csproj", "{ }"`) is the unique project identifier. You should not change the first, but you can set the second to a unique ID. – seangwright Apr 28 '18 at 19:53
  • Interesting... as you can tell, the secondary IDs are all unique as is. Why would the Xamarin project then have the same ID as the regular .NET Framework project? Should they not be different, if they signify a different project type? And why would VS accept my randomly generated project ID? All valid questions, and I will likely not get any answers to these questions. Thanks for the input though, I will keep this in mind if I run into this problem again. – Samir Apr 29 '18 at 13:26
  • @seangwright Did you have the same problem? Were you able to solve it by changing the secondary IDs? – Samir Apr 29 '18 at 13:32
  • I found no reference to these GUIDs on Microsoft docs, but there is a good list over at [Code Project](https://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs). – Samir Apr 29 '18 at 13:35
  • Checkout the dotnet project system repo https://github.com/dotnet/project-system/blob/master/docs/opening-with-new-project-system.md. Took a but of googling but it has a reference to the new and old project guids which it seems you have a mix of. – seangwright Apr 29 '18 at 14:05
  • downvote - the author's comments here demonstrate that he just *thinks* this is the solution, but he clearly doesn't know and the link that @seangwright adds in a comment demonstrates that this answer is erroneous. I'm surprised the author hasn't deleted this answer. – lukkea Jul 03 '18 at 07:21
  • The author humbly admits that he does not know all of things. The author does not think this was the solution to every possible combination of problems, the author knows this was the solution to his original problem. That is why the author decided to post the answer to his own question, Q & A style. Other people's mileage may vary, of course. Disclaimer: it may not be a pretty solution and it may be erroneous, or outright dangerous. Thus, author suggests taking this answer with a good pinch of salt and using it at your own risk. – Samir Jul 03 '18 at 10:55