I'm very new to Visual Studio and Universal Windows Apps Development. As a part of the course, I have this codeSHOW project provided.
I've cloned it successfully in VS 2015, but I can't run the project using the .sln file. Error:
Here's the error log: http://pastebin.com/c012Bba4
I have no clue how to fix it, and the issues on github go unanswered so I can't expect much from there.
This is an known issue in Visual Studio 2015.
The problem is with files with the exact same name under different folders in a Shared project, which in your case is "resources.resjson".
The only workarounds are either to make the file names unique and if that is not an option, to duplicate the files in the projects instead of sharing them out of the Shared project.
This is a VS2015 specific bug, the solution loads just fine on VS2013. You can get some insight into what is going wrong. First note that your got two message boxes that announced this error. Barely visible in your screenshot.
The failure.txt file gives more hints, you can see the stack traces of the two AggregateException that are raised when the solution is loaded. You'll see that two tasks are trying to load the same resources.resjon project item. Not correct of course, quacks like a standard concurrency bug.
Nothing actually goes wrong, Visual Studio can handle the exception and declares it "Recoverable", the projects are still loaded correctly. And compile just fine. Only other thing you need is the Bing Maps SDK, you can download the correct version here.
If you have VS2013 then prefer that version, it doesn't have this bug and loads the solution without any complaint. And minimizes the odds that you'll run into other quirky problems. Given the current stability of VS2015, not great, it is the best way to avoid losing time. Otherwise just ignore the mishap and close the message boxes, some future Update will no doubt fix the bug. You can report it at connect.microsoft.com if you wish. Not actually necessary I think, it looks like VS is phoning home.
I installed VS2013 (v12.0.21005.1) and added ReSharper 8 (v8.0.2000.2660) a day or two ago. That day it was fine. Now I'm lucky if I can get it to open one solution in a whole day. It opens OK by itself, but when I try and open a solution from within - via the menu - it hangs, badly. If I right-click a solution in Windows Explorer and 'open with VS 2013', it opens then hangs, in exactly the same way. Every now and again, for hours, I get a little notice that it's busy with something.
Anyone know what could be wrong, before I endure a reinstall that doesn't fix the problem?
Sometimes it's enough to simply delete the ".v12.suo" file and try to open the solution again. Helped me many times when VS2013 was freezing on loading a project.
Deleting all ".suo" files worked for me. There were several copies due to opening the solution in multiple versions of Visual Studio.
Edit:
Possible path could be:
PathToSolution\.vs\ProjectName\v14\
.vs may be a hidden folder.
.suo is filename.
Basically it could be anything, but you can try a few things:
Turning it off and on again.
Clear the ReSharper cache, it's in %LOCALAPPDATA%\JetBrains\ReSharper\<CurrentVersion>\SolutionCaches, where you should find a folder matching the solution you are trying to open. Just close all instances of VS2013, delete the folder and try again.
turn off ReSharper: Tools > Options > ReSharper > General > Suspend
uninstall ReSharper completely and see if problems persists.
Repair Visual Studio through Programs and Features.
I found the following to be the better approach to debugging VS based on MS Connect instructions
Please help to confirm if your captured dump file is a 32-bit dump file. If it is a 64-bit dump file, please use the following step to capture a new dump file.
Start Visual Studio.
Start another instance of VS.
In the second instance click Tools | Attach to Process...
In the list of processes locate devenv.exe.
Click Select... and explicitly choose 'Native' and 'Managed' code.
Click OK and OK to close Select dialog and Attach to Process dialog.
Go back to the first instance of VS and repro the hang.
Upon the hang, control should go to the second instance of VS. If not please go back to the second instance of VS manually, and hit "Break All".
In the second instance click Debug | Save Dump As Minidump with heap.
If you are running the VB profile you will not see the Save Dump As menu item. To add this menu item:
Select Tools -> Customize
Select the Commands tab
Select Debug from the Menu bar dropdown
Click Add Command...
Select Debug from the Categories list.
Find the Save Dump As entry in the Commands window.
Click OK (the Save Dump As... command is added to the top of the Debug menu).
Click Close
You can get detailed steps about how to get the dump file and call stack at http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx
If you find the problem is with Resharper Addin you can then report the issue via - http://youtrack.jetbrains.com/issues/RSRP
Suspending Resharper Worked for me.
Goto
Tools -> Options -> ReSharper -> General -> Suspend Now
Now your solution will load very fast.
After your solution fully loaded, you can change the Resharper settings to Resume Now.
Are you using any node modules in your project? Or can you identify that it is a ReSharper specific issue?
If you've got NPM modules (eg. for Grunt), mark your 'node_modules' folder as 'hidden' (no need to make child folders hidden though), and try again.
Visual Studio was hanging on open for me, turned out it was trying to scan deeply nested node modules with file paths longer than the Windows maximum (260 characters), and this was preventing me from opening the solution in VS, but marking the folder as hidden solved the problem.
I had this issue recently as well, and found that disconnecting my computer from the internet when loading the project fixed it. With this, I managed to cut loading times from several hours down to seconds. Since my network cable is not particularly accessible, I simply disabled my network adapter before loading the project (in Control Panel).
This soon became frustrating, however, and I recently looked into the problem again. It seems that logging on to my Microsoft account in Visual Studio ultimately fixed the problem, and I now have no more issues loading projects.
This may work for you as well (if you haven't yet fixed it - but since there is no accepted answer here, I assume that the problem is persisting), so I suggest that you at least try disconnecting from the internet, even if you would rather not enter your Microsoft credentials.
I went into the %LOCALAPPDATA%\JetBrains\ReSharper\
and opened all the directories looking for the SolutionCaches, and emptied all of them. Problem solved. The application was quite large, so this helped.
Check for Windows updates
I had this problem too. Furthermore, I couldn't open my Windows firewall settings (trying to block VS's internet connection).
When opening update settings (Windows 8), I saw there was a pending update ("found today"), so I rebooted my computer, letting Windows update. After that, VS and the firewall worked fine again.
Check your hardware
I've had the problem a second time; even Windows 8's update page would keep loading forever. It was an issue with my (non-OS) hard drive: https://superuser.com/questions/756261/various-parts-of-windows-8-and-visual-studio-2013-get-blocked-by-possibly-comm?noredirect=1#comment978074_756261
I get this issue now and again - VS 2013 Update 2, Win 8.1, IE 11.
Try this - Open task manger, kill the VS app hanging, and then close any IE sessions that are running in the Background Process list - there may be one or more hanging around.
Restart VS
Seems to clear it for me, without a reboot.
The problem I had was the Perforce connection.
When opening the solution, it would ask if I wanted it to connect to Perforce. Allowing it to try would make it hang and allocate 1.5 GB of RAM.
Not allowing the P4 connection let it load properly (allocating 1 GB RAM). Then I could tell it to connect to P4 after, and it is now fine.
For me , whether computer crashes with power outage, or sometimes with mandatory reboots in the middle of the night. What does WORK for me
DELETE ALL FILES IN THIS DIRECTORY:
C:\Users\yourusername\AppData\Local\Microsoft\WebsiteCache\
For anyone still referring this helped me:
I had to always delete .vs12.suo file to load the project.
I came across this thread from Microsoft and following that I created registry entry which fixed my issue with Solution load.
https://connect.microsoft.com/VisualStudio/feedback/details/860685/visual-studio-hangs-after-10s-when-loading-solution-corrupt-suo
I had similar issue, when i checked the solution file it was created by VS.Net 2012. To resolve the issue, I created dummy solution file and reloaded the projects from vs.net 2012.
Also observed when nuget package update got screwed up, while you reload the solution, Visual Studio might get hang.
The Visual Studio might go hang, when there was a problem in loading the nuget packages.
In my case, VS 2013 Professional was hanging on every startup, even without opening a solution because the license was no longer valid.
Last item in the log file:
<entry>
<record>367</record>
<time>2015/07/13 20:11:05.051</time>
<type>Information</type>
<source>UserConnection</source>
<description>myemailaddrs#gmail.com signed in for IDE user</description>
</entry>
And on the msdn.microsoft.com subscription page: "Your subscription is no longer active, contact your administrator."
I had to get an updated subscription from my employer.
Deleting Test Results from my TestResults folder actually did the trick for me. Just another thing to try.
VS2012 hangs on me e.g. when opening a csproj file on a network share (in fact on a share that was on the VirtualBox host, connected as a smb share using a VirtualBox feature).
Copying the project over to a local drive fixed it for me. Not sure if assigning a drive letter would do the trick.
Also not sure why it does not work via network share, if it is a VS limitation or perhaps some plugin (I use resharper, of course).
For me this appears to have something to do with the project having the MVC 4 project type guid (E3E379DF-F4C6-4180-9B81-6769533ABE47). Removing this guid from the .csproj resolved the hanging for me. (An additional wiping of the .vs folder was required after removing the guid.)
I just removed "packages" folder from root of solution and it helped for me (Visual Studio Express 2015)
Sorry for having to create a new post instead of commenting on the selected answer .. I do not have enough rep to comment at this time.
My issue was was temporarily resolved by the "...delete the .suo file ..." solution, and as other folks pointed out, I had to delete the file every single time.
Since it (apparently) is impossible to stop the creation of the file I started to dig a little more into what the file did. In addition to saving user settings, I believe it is also saving session settings, like which files you have open when VS is closed. I suspected that my project is attempting to open a file that no longer exists and that is what is causing the hang. What fixed things on my end was to delete the .suo, open VS, open a file within my solution, build and close the solution. After doing this I have had no hangs.
tl:dr
In my case, a user setting file(.suo) was attempting to open a file in my solution that no longer existed. I resolved the issue by performing the following steps.
Delete the .suo file (for me this was in /[projectfolder]/.vs/[projectname]/v14
Open Visual Studio
Open your project
Open a file (I simply opened a random .cs file)
Build and save your solution (Simply saving may do the trick, I built by habit)
Close Visual Studio
Hope this helps someone ... we spent way too many hours on this issue :)
Lots of suggestions here and elsewhere but the only thing that permanently worked for me had to do with the start-up project I'd set. This is what I did:
Delete the .suo file as suggested elsewhere.
Start VS and open the solution. All should be well at this point.
Leave the start-up project as-is, even if it's not what you want.
Save the solution. (Possibly do as someone else suggests and open a file, clean, build/re-build, etc, but I didn't have to do any of that.)
Close the solution and exit VS.
Re-start VS and open the solution.
Change the start-up project to whatever it should be
Save the solution. (Possibly again do the open file, clean, build/re-build, etc.)
Close the solution and exit VS.
Restart VS and re-open the solution and all should be well.
This might or might not work for you but I'd tried everything I could find - registry changes, debugging VS from a second VS session, you name it - but nothing else worked for more than a single start/open.
Try to uninstall extensions with "Control Panel" or disable any add-in in [Tools]=>[Add-in Manager] then try to reopen the solution.
My problem was fixed by uninstall "Visual Localizer".
In my case the Fusion log has been enabled. Log files has been growing for months as I forgot to turn it off after investigation. This way the antivirus software started to check these big log files several times during opening the solution, and "Preparing solution..." message is visible for long-long time. When I noticed this, I turned off the fusion log, and problem solved. Solution loads in 10 seconds instead of 20 minutes.
I've had this issue multiple times, in pretty much all versions of VS. The one solution that seems to work most of the times is to delete the .vs folder located in the solution folder. Sometimes it's enough to delete the .sou file located in .vs///
The folder is hidden by the way, so you will have to enable "Show hidden files and folders"
For me the solution was to disable source control (Set plugin to None in Tools->Source Countrol). I think it was trying to sync some huge Git repo for some reason (have a couple of massive repos, but not in the tree I was trying to open).
I have fixed the issue by uninstalling these two plugins:
Productivity Power Tool
Web Essentials
I restored a previous version of the .vbproj file and it solved it.
I don't know what was in the newer version but the problem was something inside the .bvproj file itself.
On the current project I am working on, there is, at the moment, a large churn of code, which means updating from source control can mean at times many csproj file changes. As we all know, VS2010 doesn't have a "Reload all" button, but you must reload each project and confirm each reload.
Is there a method where either the project is auto-reloaded or the IDE can detect this and ask for a solution reload?
Finally found a solution:
http://lostechies.com/jimmybogard/2011/01/27/reloading-all-projects-with-vscommands/
Quoting from the site:
Quite often I’ll find myself working
in situations where multiple projects
have changed, and Visual Studio asks
to reload them, one at a time. This
happens when I’m working a lot with
source control, and doing things like
switching branches, performing merges,
or just integrating upstream changes.
I have to click “Reload” a million
times for each project that changed on
disk, and it’s quite annoying. On top
of that, VS forgets which files I have
open, so every file that I was working
on gets closed.
I may be the last VS user to find out
about this, but a free lite version of
the VSCommands plugin is available on
the Visual Studio Gallery that does
just what I need – reload all changed
projects at once, preserving which
files I had open:
It's a pain, but the best option I've found is to Close the solution before Getting the latest source code.
If there are more than two changed projects, it is faster to manually unload&reload the entire solution than it is to Get and wait for it to unload&reload the affected projects only - reloading projects is achingly slow (even disregarding having to click the OK button for every project that changed).
(In my mind the real question is: Why does it ask that question at all??? If you Get the latest source code, there is absolutely no sane reason why you would want to only use part of it. It's like a petrol station attendant saying "You've bought some fuel. Would you like me to now actually put it in your car, or shall I just pour it out on the ground?")
Well, that doesn't work if your references paths changed in the csproj file and your using something like the sysinternals junction tool to change a symlink. E.g. tool switches D:\Projects symlink from D:\Baselines\1.0\Prjects to D:\Baselines\2.0\Projects , and because someone changed the folder structure between 1.0 and 2.0, your .csproj file suddenly points the dll path from ....\References\some.dll to ....\References\3rd-Party\some.dll . I know that is a special case, but happens (e.g. in my company).
There is an alternative solution though, one which I highly recommend as it has other benefits, too: the not-so-well-known VS 2010 Extension Solution Load Manager. It defers loading of Projects to the background, or until manually loaded, improving solution load time a lot for large solution files. It has this "reload solution" button in it's menu (unfortunatlely there seems to be no shortcut) which then reloads all solutions from scratch, skipping/backgroundloading the solutions you set. A Microsoft guy commented on his blog that they wanted to include something similar into VS 2010, but the feature didn't quite make it.
Sure, it may take longer then "just" one click and updating 100 documents, but it solved my problem of (relative) reference path changes, and gives a nice speed boost every time I open an at least medium sized solution.
Edit as of Oct 2013
VS2012 includes this functionality by default. At least the async loading stuff. The "don't load at all" functionality is unfortunately only possible by using manual "unload project" in VS2012. But as pr-project memory consumption did go down with VS2012, it's not that big of a deal anymore.
If you have checked the option "detect when file is changed outside the environment" in the "Documents" section of options, projects and files are reloaded when changed. It works for me when switching branches in git.
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.
Every time I open a windows forms application in VS .NET it takes minutes to initialize the Toolbox. Is there a way I can tell VS to cache this toolbox somehow?
Turn off AutoToolboxPopulate in Tools->Options->Windows Forms Designer->Tools.
The ToolBox has a nasty habit of collecting garbage. It was pretty bad in VS2005. But recently discovered that VS2008 suffers from it too. On Vista, navigate to c:\users\yourname\appdata\local\microsoft\visualstudio\9.0. There are some hidden files there. The toolbox_reset.tbd and toolboxindex_reset.tbd files seem to be backup files to get out real trouble, there to copy over the hidden toolbox.tbd and toolboxIndex.tbd files.
Take a look at the ProjectAssemblies folder.
This probably has to do with installed packages, try:
devenv.exe /ResetSkipPkgs
and then
devenv.exe /Setup
VS Toolbox consumes most time by going through installed Packages...
Opening the ToolBox the first time will certainly have a delay but it should only be the first time it occurs. If you are seeing repeated delays then it's likely one of the following.
A Plugin : What plugins do you have installed? Try uninstalling them and opening the toolbar a few times. That will eliminate the plugins as a suspect
A custom control: If you make custom controls they get added to the toolbox. It's feasible that this could be causing some performance issue (unlikely though). Try commenting out the functional code in the controls and see if that improves performance.
Deleting the .TBD from visualstudio\9.0 worked for me but result in a popup TFS30330: Team Explorer cannot write the to the project list configuration file. Also the files were recreated during VisualStudio2008 initialization but the initializing toolbox... does not occur. The TFS30330 error occurs each time i launch VS2008. I then had to reset my Visual Studio settings. But in the end it was worth it - no more forced coffee break as one blogger apptly put it.