I found the following information about the Microsoft Visual Studio "extra" files:
What is the purpose of the vshost.exe file?
My question is, is there a way that I can NOT have the .pdb, .manifest and vshost.exe files from being made? Or are they absolutely necessary?
I just noticed that after debugging it, it's still showing up as a running process in my machine which worries me since I already closed it.
Switch to the Release configuration. Then Project + Properties, Debug tab, untick the "Enable the Visual Studio hosting process" option. Build + Clean, you can delete anything that's left and it won't come back. That this option is turned on by default for the Release build is, arguably, a bit of a flaw but defensible.
The hosting process is a custom hosted version of the CLR. Exactly what it does is not well documented but it is related to configuring the security settings of the primary AppDomain. I've never heard anybody complain about battling CAS problems without it, but then it is unusual to turn it off and your app almost always runs in full trust when debugging from the IDE. It would matter if you build to a network share on early versions of .NET. The only thing that's obvious from disabling it is that anything you write with Console.Write in a gui style app will no longer appear in the Output window. It has nothing to do with speed as claimed in the highly upvoted answer in the link, the core framework DLLs are already resident in RAM since VS and MSBuild uses them.
Best thing to do is just not worry about it too much. A Setup and Deployment project will ignore it.
Regarding vshost files, at least in VS2010:
They are not generated on build, but on selection of build configuration (it will be generated in release when we select release for the first time) and on setting "Enable the Visual Studio hosting process" to true. (As configuration debug and this option set to true are defaults, vshost.exe will be created in bin/debug on opening VS with target project by default.)
They are not cleaned on rebuilding or cleaning the project, but only manually when "Enable the Visual Studio hosting process" is false if VS with that project is open. (And it won't be generated anymore when opening this project.)
If this flag option is true and VS with target project is opened, this file cannot be deleted as being used. Once when it is unchecked, vshost.exe can be immediately deleted.
Summary: Generating and removing these files is not related to build process.
Also, I may add that option "Enable the Visual Studio hosting process" in referenced projects which are class libraries is not considered. This option is only considered for target project which generates executable file.
Related
So, what is the problem?
The problem is that Visual Studio considers .csproj.user a dependency of the project being run.
Let us assume the following:
We have a freshly built solution containing a web application project X as the Start Up project.
There are Silverlight applications served by the X web application.
There is no X.csproj.user file initially.
Now consider the following flow of events:
Open the solution in the Visual Studio
Build.
Run.
A dialog is open to ask whether Silverlight debugging is to be enabled. Enable it.
Stop the debugging session.
Run again.
Stop the debugging session.
Run again.
Assuming nothing is built at step 2 (because the solution is totally up to date), will there anything be built at steps 3 and 6?
The answer is affirmative and here is why:
The X.csproj.user file is actually created by Visual Studio when the project is requested to run. What happens next is that the X.csproj.user file is considered a dependency of the project X by the Visual Studio. Being created just now the file is newer than the project binaries and so Visual Studio builds the project X. This explains why the project is built at step 3.
When we agree to enable Silverlight debugging Visual Studio records this agreement in the X.csproj.user file. So the file is modified again, after the project has started running. Restarting the debugging session is going to build the project X yet again, after all X.csproj.user is again newer than the binaries built a second ago. This explains why the project is built at step 6.
Fortunately, nothing is built at step 8.
Call me petty, but I want to avoid the builds at steps 3 and 6. The problem is that I am not allowed to check in the X.csproj.user file, because that is likely to create a mess with people accidentally checking in their private changes.
On the other hand, I am unable to move its default content (along with the agreement to enable Silverlight debugging) into the X.csproj. Well, I can, but it is just being ignored.
So, here is my question - is it possible to separate the content stored in a .csproj.user into two groups:
Permanent. These are the things I would love to have in the .csproj file. It will be checked in.
Temporary/Private. These are the things private to individual developers. Never checked in.
Visual Studio already allows this separation for certain properties - see the Apply server settings to all users (store in project file) checkbox in the Web properties tab of a Web application project - http://olalalittlen.wordpress.com/2011/07/20/vs-tips-managing-server-settings-in-web-projects-for-multi-developer-scenarios/. However, it is insufficient.
Any other ideas on how to prevent the aforementioned redundant builds are welcome too.
Probably between 25 and 50% of the times I build my solution, I see this:
"The operation you requested is taking longer than expected to complete. This dialog will close when the action completes."
I hate this window in ways I can't describe. It never resolves, the Cancel button is never enabled, and the only way to remedy it is to kill the devenv process and load up my entire solution again, knowing full well that I've fixed nothing and I'm equally liable to see the same thing when I attempt my build.
My solution is about 60 projects in total, which are mostly C# class libraries, with a few each of web applications, web services, and console applications. However, the problem persists even when building one slice of the codebase with the majority (50) of the projects unloaded.
My problem is that the output windows doesn't tell me anything at the point at which it freezes, and I don't know how else to determine the cause of this lockup. If I were to guess, I would assume that it's a deadlock in the filesystem or something, but I don't know how to go about proving this--much less how to prevent it.
What can I do to diagnose and eliminate this from my solution so that I never see it again? In general, how can I diagnose problems that occur during a build?
Had a similar issue, VS would hang for 45 or so seconds then build for 4 seconds and complete. The 45 seconds of hang would not produce any output to GUI and VS would hang.
Using ProcMon I could see 3 million+ file operations on the /packages/ folder via devenv.exe when I would build this project (and would continue for some time after)!! The first steps of the build you can see that it was checking EVERY PACKAGE to see if it needed to do a package restore (it did not).
Since I tend to blame NuGet for everything, I disabled NuGet Package Restore "allow NuGet to download missing packages" checkbox under Visual Studio -> Options -> Nuget Package Manager -> General. To my delight, the build was very fast. 5 seconds total!
Turns out that we had enable package restore on build enabled (I think this is on by default now in VS) AND we also had the packages checked into source control. It seems this causes TFS to thrash in some way... Checking for restoring packages must trigger TFS to do some source control operation checks.
FYI this was VS2013 UPDATE 4 - Nuget version: 2.8.50926.663, on a sln with NumberOfProjects = 38, but I could recreate this hang just building a single csproj with 2 dependencies.
Update:
Localhost "Rebuild All" on Sln with SccNumberOfProjects = 53 was taking 7:05 with 2 minutes of visual studio frozen / unresponsive
down to 4:14 on a 2 core i5 with no freezing
down to 2:44 on a 4 core i7
Also: This was on a machine with various file watcher security tools, likely not adding any speed to this whole process... and possibly to blame.
Update in 2021:
If you are looking for a paradigm shift, the new SDK style csproj format (see migration tool) + nuget PackageReference makes updates almost instant (< 20 SECONDS for same projects in scenarios above) - highly recommend you upgrade any legacy projects.
** Known incompatibility - website package references do not support static file references via nuget ( checkout LibMan)
I have seen this happen on large projects when MSBuild is running with the diagnostic switch turned on. In Visual Studio, go to Tools / Options / Projects & Solutions / Build And Run, then check the MSBuild project build output verbosity value. If its not set to Minimal, try setting to minimal and see if your builds are able to complete.
I did not try any of the above solution as by the time I tried my approach - all was well again.
My steps are as following:
Close VS
Delete the .vs folder
Open my solution
Clean Solution OK
Build Solution OK
Optional Rebuild OK
In my case setting "maximum number of parallel project builds" to 1 kinda helped (i.e. building a project from clean state causes 1 min freeze followed by normal build and every subsequent build works fine).
Aforementioned setting can be set in Tool -> Options -> Projects and Solutions -> Build and Run.
Seems like running Visual Studio as Administrator solved the problem for me! (For always running a program as Administrator see How to Run Visual Studio as Administrator by default)
I've found Visual Studio hanging a lot on building larger projects. Turns out it was ReSharper. After I turned it off: Tools -> Options -> ReSharper -> Suspend Now, everything built fine no issues (even on very large solutions, 100+ projects)
There was a suggestion on Microsoft Connect that Modelling project was responsible for the freezes. I removed a Modelling project from our solution and have experienced no freeze since then (about a week).
For me it was something to do with npm package install that ran automatically. I went to Tools > Options > Project and Solutions > External Web Tools and unchecked all external tools and restarted VS. After that, I was able to build it again. I know I need them to be checked but I need to figure out what's triggering them and what's wrong with this solution file.
VS2019 exhibits this issue as well for me, in my case, the problem was because of dependencies stored on a network share. I have a hunch that Windows Defender Antivirus was scanning a lot of extra stuff that was in the network share, which is only accessible when connected to a fairly slow VPN.
For me the issue was witch an extension that automatically runs T4 templates on build (AutoT4). Disabling it when working with solutions with EF fixed the issue.
I moved my VS 2008 development platform from Windows 7 to Windows 10 and encountered a situation where Visual Studio would hang up every time I tried to build a large project. I had to build the project, then use the Task Manager to kill VS and then restart. Needless to say, this made debugging really difficult! Anyhow, the problem was that in moving to Win 10, VS was no longer running as administrator (and perhaps Win 10 is more particular about privileges). Changing the properties so that the program ran as administrator resolved the problem. (IngoB -- I don't have enough status to comment on your post, but thanks for pointing this out!)
Just try below command with admin mode. Before running this command make sure to close all VS instance.
devenv /resetuserdata
Note: devenv is located at C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE
In addition to the felickz's answer which solves (or almost solves) this problem for builds:
Except the problem during a build I also had problem with the Package Management Console. It took about a minute to wait for it. Using the procmon I found that the NuGet repository folder was parsed each time this window is opened (very smart, Microsoft!). There were about 1000 packages in this folder. After removing everything from the above folder the performance problem diapered.
Note that my answer relates to the VS 2015 (and may be below). I didn't tested, but suspect in VS 2017 it should be ok.
Visual Studio 2017
Removing Anaconda3 from the installation fixed it. In procmon I saw hundreds of thousands of calls looking for files in the Anaconda3 folder from hundreds of instances of powershell spawned by msbuild.
I had this problem because of an issue restoring nuget packages. There was a duplicate entry in the packages.config file. Rather than report it as an error, the build would just hang forever.
I didn't discover the problem until I tried to restore the nuget package through the "Manage Nuget Packages..." option in the menu. After removing the duplicate, the build completes properly.
Where does the indication of unavailable or available (loaded) projects / websites is saved?
I have a solution which has some unloaded projects while only the website is loaded
Of course I can right click and reload it but still, I want to now where this [unavailable or available] info is saved?
I've been looking in the sln, there is no difference (beyond compare) between loaded one and unloaded one.
Also in Websites.xml, there is no such difference
The suo file stands for "solution user object" (it's a guess).
It's a per-user container of solution settings.
You can safely delete it, but you will lose some other non important things, like breakpoints, and so on.
In most VCS, this file is in the standard exclusion list, as it should remain specific for each user. This is the evidence you can safely delete it.
I believe the information regarding loaded and unavailable projects in a solution is stored in the .suo file. As mentioned previously, this is a user-specific, binary settings file auto-generated and maintained by Visual Studio.
It's worth pointing out that some projects won't load if the machine doesn't have the relevant software installed (e.g. an MVC web application project won't load on a machine that does not have it installed; similarly for WIX projects).
If you have intentionally unloaded projects to improve the overall load time of your solution, then you should know that Visual Studio 2012 now supports asynchronous loading of projects.
You might also have a look at spinning some projects out into other solutions, grouping by major system features (be wary of breaking project dependencies.)
I have a Visual Studio 2010 Ultimate C++ project (not managed or .NET). When I press F5 (i.e., start debugging), I want it to save all the files, rebuild those that changed, link the whole thing, and then run. Instead, it appears to use the last build. Thus, when I try to step into a function or something, I get the following error:
Based on my research, I have verified these options, the first three of which are in the Options dialog (can be reached under "Debug->Options and Settings"):
"Projects and Solutions->Build and Run->Only build startup projects and dependencies on Run" is checked. Some research indicated that it should be unchecked, but in my case I actually do only want it to rebuild the startup project. For what it's worth, I've tried unchecking it, with no effect.
"Projects and Solutions->Build and Run->On Run, when projects are out of date:" is set to "Always build".
"Debugging->Edit and Continue->Enable Edit and Continue" is checked, though it's greyed out.
In the Configuration Manager ("Build->Configuration Manager"), all solution configurations and platforms have their "Build" checkbox checked.
I have also tried deleting all Debug and Release directories as well as the .sdf and ipch directory.
For completeness, I suppose I should mention that I'm using precompiled headers, though I kinda doubt it matters.
[EDIT: I should note that it only seems to be one file (a .h file) that's doing it. I tried renaming it and recompiling, and also removing it from the solution and adding it back in, but it didn't work. ]
I was able to bring my solution back into the right state after deleting all .suo and .csproj.user files. Answer led to this solution. Hope this saves someone time.
I fell into this state after installing Ultimate over Professional and running profiling tools.
Once I had similar problem with my C# project and I think I have tried every possible suggestion available on internet but none worked and then this is what I have done:
Created an empty Project
Added startup function to verify that it does not show any error
Imported all my source code manually one by one
So, Yes, it was the solution. You already have done a lot so I would say you can get lucky by trying here and there however having a new project and importing your individual source file would be faster.
Another solution could be that switching the platform. I noticed that when I when to project properties, the new project I had just created had a platform of 'win32' and my other projects in the same solution had it set at x64. After I switched my project to x64, everything worked just fine. This worked for my interop(C,C+, C#) project and hopefully works for other projects as well.
I have successfully resolved it, try the following:
remove all temporary and intellisense files
remove all project from solution and then add them back(most important)
check projects 'Frameworks and References' to ensure they are valid
I have a solution in VS2008 containing C# and C++/CLI projects. There are 3 "solution platforms" in my solution:
Any CPU
Win32
Mixed Platforms
I never want to "just build the C# ones" or "just build the C++ ones", I always want to build all projects. So the solution platforms metaphor is meaningless to me, I'll leave it on Mixed Platforms or whatever as long as they all build.
Now VS sometimes automatically switches the current solution platform to Any CPU (I'm not sure when or why). This means that pressing F7 will only try to build the C# projects, which is obviously no good. So I have to switch back to Mixed Platforms and try again.
So how to workaround this irritating problem? I have tried 2 ways:
In Configuration Manager, remove the Any CPU and Win32 solution platforms. This worked until I added a new project and Visual Studio very kindly added them back in... :/
In Configuration Manager, check all checkboxes for all projects in all configurations in all solution platforms. This becomes a nightmare to manage with many projects in the solution.
Any other ideas?
See the msdn:
http://msdn.microsoft.com/en-us/library/ms165408.aspx
Removing a Platform
If you realize that you have no need for a platform, you can remove it
using the Configuration Manager dialog box. This will remove all
solution and project settings that you configured for that combination
of configuration and target. To remove a platform
On the Build menu, click Configuration Manager.
In the Active solution platform box, select <Edit>. The Edit Solution Platforms dialog box opens.
Click the platform you want to remove, and click Remove.
At least on Visual Studio 2005: After removing it from configuration manager, it is also necessary to edit .vcproj as text file and remove any references to Platform manually.