I had been trying out some of the Performance Profiler tools in VS 2017. All was working great except when I tried the Instrumentation profiling method. It asked to elevate the permissions of that process. Which I did.
Now every time I try to debug my app, I get an error that the VSPerf "Instrumention" Tool has stopped working.
I've tried everything, clearing out my .vs folder, bin folders, looking through the .csproj and .sln files. Completely repairing Visual Studio and removing whatever references I could find to "performance" in the options. It's getting really irritating.
Any suggestions?
Related
I keep getting this error during the publishing of my VS 2019 C# win forms project
Unable to copy file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.TextManager.Interop.8.0.dll" to "bin\Debug\app.publish\Application Files\Database Client_2_0_0_47\Microsoft.VisualStudio.TextManager.Interop.8.0.dll". Could not find a part of the path 'bin\Debug\app.publish\Application Files\Database Client_2_0_0_47\Microsoft.VisualStudio.TextManager.Interop.8.0.dll'. Database Client
This also happens with 4 other DLL's with some being from VS 2019 itself and some from NuGet packages
This has only started happening recently so I'm unsure whether this is an issue with VS 2019 as no fundamental code has been changed and the only thing that has is some logos on a few .rdlc documents (Microsoft Report Viewer).
I'm running VS 2019 Community on version 16.11.4 with only .Net Desktop development, Office/Sharepoint development and a few individual packages installed.
I've looked around and can only seem to find people having issues with the .exes themselves due to them still being open however this is not the case for me as I have checked and there are no background processes like devenv.
What's strange is both the Debug and Release build fine with no issues whatsoever.
I've also tried deleting the \bin and \obj folders to no avail.
Below are some images of my settings that involve publishing
Publishing Main Settings
Prerequisites
Deployment
It seems the solution to this problem, as #HansPassant commented, was to shorten the build path as it was exceeding the MAX_PATH variable.
Once my project was moved from the default C:\Users\Drew\source\repos\ to just the C:\ drive my project was able to publish successfully.
I know this question was asked before but I couldn't find a solution that helped me anywhere and feel hopeless.
I'm developing asp.net web sites using iis express.
Recently after accidently messing with visual studio installations I started getting error 500.21 when running any web application through visual studio (I tried running it from all three I have installed - 2013, 2015, 2017). When doing so I get:
error 500.21 - 'Handler "ExtensionlessUrlHandler-Integrated-4.0" has a bad module "ManagedPipelineHandler" in its module list.'
All the projects web.config file has not been changed, it is working for my other team members and has worked for me before, therefore I don't think the problem is there.
Things I've tried to track the issue:
When running sites directly using the IISExpress exe through the cmd, they run perfectly, which makes me think the problem is related to visual studio perhaps, and not related to IISExpress or it's applicationhost.config which seems to be ok.
Countless of reinstall/repair operations on all visual studio/iisexpress/aspnet components I have on my computer without success.
Running the "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i" which was mentioned alot when I searched this issue. Not working.
It took me a while to figure out that the applicationhost.config that visual studio references to when running sites on IISExpress was in the .vs folder and not in the IISExpress folder itself.
The file in the .vs folder was corrupted and after replacing it with the applicationhost.config from the IISExpress folder things started working out
When I build a C# program (this has been going on for several different solutions/projects I have been working on) in Visual Studio 2017, the new, updated code will build and run in debug mode (and run correctly).
However, the application that Visual Studio has been outputting when I build/debug them has been remaining with the original, first version of code that I saved. When I choose the options to rebuild, it will update the time stamp on the application and .pdb files, but the application will perform the way it did in earlier code versions, not the most recent code version that was running problem when I ran debug mode immediately after pressing Ctrl + F5.
These are C# Console Apps with the .NET Framework 4.6.1, if that makes any difference. I checked the output folder, and it is indeed the desired folder and the one I have been looking in... so why is the time stamp updating on the application (.exe file) that it outputs, but not the code itself? What am I missing?
When I run into strange things like this in Visual Studio, the first thing that usually works is to clean the project and rebuild. If that doesn't work, I'll close Visual Studio, re-launch, then clean and rebuild again. If that doesn't work, I would start looking into any extensions you have installed that might be getting in the way of your build process.
Further, you can look into logging the extensions activity to help troubleshoot if there are issue there. See the following article:
https://blogs.msdn.microsoft.com/visualstudio/2010/02/24/troubleshooting-extensions-with-the-activity-log/
You may have already tried this, but since it wasn't mentioned I thought I'd provide it for others in a similar situation.
Two possible reasons:
(1) Your project was not recompiled during debugging. Please enable Edit and Continue under TOOLS->Options->Debugging.
(2) Visual Studio has a concept of incremental build. If you have a solution with two or much more projects and if you change source code in only one of the two projects, the "Build" command will compile only the modified project. But the "Rebuild" command, on the other hand, it will recompile all projects in this solution.
I've got a C#/WPF application which was originally built in Visual Studio 2012. Eventually we upgraded to Visual Studio 2015 and that worked fine. Lately I've upgraded further to Visual Studio 2017 and now I'm having lots of problems. I've got the drop-down options set to "Debug," "Mixed Platforms," and my project name, and when I hit Start it does indeed start up my project. However any recent changes I make to the project don't get reflected.
At first I was wondering why a TouchUp event handler I had added wasn't seeming to be hit. Then after further experimentation, I changed one of the existing log messages slightly (we have a logger that logs to a local text file). However, it continues to log the old message. Another symptom of this is that none of my breakpoints get hit. When I add them it shows up as the standard red circle, but as soon as I press start they change to a white circle with a red perimeter, and the tool-tip hint says that it cannot hit the breakpoint because the source does not match what is running.
This is extremely frustrating as the debugger is one of those things that should just work. Has anyone else run into anything similar after upgrading to VS'17? Any advice?
So I found a workaround to my problem, but not a solution. When I deleted the files from the "bin" folder, it just stopped working altogether. So instead I manually built the project using MSBuild, in the C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin folder. The two commands I ran in succession were:
MSBuild.exe /target:Clean /p:Configuration=Debug /p:Platform="Any CPU" MySolution.sln
MSBuild.exe /target:Build /p:Configuration=Debug /p:Platform="Any CPU" MySolution.sln
In fact, I don't really need to do the "Clean" step every time, and this works. However it's really quite slow and I am genuinely surprised that VS apparently isn't doing this automatically, under the hood.
Yesterday, I encountered the problem multiple times that Microsoft Visual Studio 2013 restart unpredictably when it loads very large C++ and C# solutions.
I researched Stack Overflow and found this particular article: Visual Studio 2013 hangs when opening a solution
which suggests deleting the suo files. However, when I tried that the problem persisted.
I also tried uninstalling and reinstalling Microsoft Visual Studio 2013 and still the problem persisted.
I then tried loading a smaller solution consisting of a C# solution and a C++ project and that succeeded in loading, compiling and linking.
I was wondering why I suddenly encountered this problem. Could the cause of the problem be related to the amount of 64 bit physical memory I have installed on my 64-bit desktop system? Alternatively, could it be due to a computer virus even though my desktop system has an antivirus package installed. We are tring to avoid reimaging the disk of my 64-bit desktop system and reinstalling all the software which could take 2 days to complete. Any help is greatly appreciated.
It's probably some plug-in misbehaving. You can try disabling them (Tools => Extensions and Updates) and experimentally determine which one is causing the issue.
If you want to go all-in, you can debug it:
Download and install WinDbg 32-bit
Run Visual Studio under windbg: windbg -g "%VS120COMNTOOLS%..\ide\devenv.exe" c:\my\solution.sln
Watch the incredible amount of debug info VS spews into
WinDbg
If Windbg breaks, inspect the stack - maybe some DLLs on it will clue you into which plug-in is the culprit.
Open file explore and past this command
'%AppData%..\Local\Microsoft\VisualStudio\12.0\ComponentModelCache'
Then remove 'ComponentModelCache' folder.
Restart the visual studio.