Since Visual Studio 2017 version 15.8 we have on some computers in my team the following really weird build error.
Additionally Visual Studio recognizes it
but the IDE itself doesn't crash.
To check if it only happens to our own solutions I created a new simple, plain command line tool project which shows the same build behavior. So it isn't exclusive to our solutions.
I tried to get help from Microsoft but it seems they don't know what to do about it. The thread doesn't show all the material I provided to them. They got a lot of logs and a sample project from me. A crash dump wasn't possible to provide, because Visual Studio itself doesn't crash.
Repair and full uninstall, new install of Visual Studio didn't help either.
Edit: It is not only occurring on my development machine but on our build servers (there are two of them), too. Interestingly our VMs on the development machines does not seem to have this issue.
To me it seems, the problem has something to do with loading assembly from GAC, so I would suggest to try reinstalling Microsoft.CodeAnalysis assembly and see if it helps.
To Do that:
Install Microsoft.CodeAnalysis package to your project with it's required dependencies, make sure to note down all assemblies being downloaded.
Run Visual Studio Developer Command prompt as an Admin
Uninstall existing assemblies from GAC by using command gacutil /u [name of assembly] (do this for all assemblies from step 1)
Install newly downloaded dll using command gacutil /u [Path to Dll] for all dlls (do this for all assemblies from step 1)
Remove package from your project
I hope this helps!
Unfortunately in this case you have only three two options:
You could try to describe all the steps to reproduce this crash so much detailed as you could with a lot of screenshot images from this steps. Use for this DOC file format, PDF or some like that. This file you have to send to Visual Studio support.
You could try to create the crash dump. Each time Visual Studio crashes, it will create a dump file devenv.exe.[number].dmp file in the configured location. Each dump file produced by this method will be up to 4 GB. in size. Make sure to set DumpFolder to a location with adequate drive space or adjust the DumpCount appropriately. I know, you wrote already on MS forum that this error doesn't create one dump. But would you like to imagine that you have 10 crashes on a day and on each crash one dump file in size 4 GB. will be written? The dump creating is disabled normaly and you have to enable it. How to enable it you could find using search string in Google: "How to enable dump files in Windows" or for Windows 10 you could see this video. Alternatively or additionally you could use the programm tool "ADPlus" for creating memory dump files and log files with debug output from one or more processes. This tool is very detailed describen on this MS Support page.
You could try to debug by yourself. But in the case if you want do it you have to see "Tools listing Included in Debugging Tools for Windows".
Normaly by Visual Studio support do not work the Visual Studio developers. You have to be nice to them and they do what they can do. You could not expect from them that they all know. They do their job using some given instructions.
In your case the support worker has gived you the link Reporting Visual Studio crashes and performance issues in which you have to read the following part:
Directly reproducible crashes
Directly reproducible crashes are cases which have all of the
following characteristics:
Can be observed by following a known set of steps
Can be observed on multiple computers (if available)
If the steps involve opening a project or document, can be reproduced in sample code or a project which can be linked to or
provided as part of the feedback
For these issues, follow the steps in "How to Report a Problem"
and be sure to include:
The steps to reproduce the problem
A standalone repro project as described above. If this is not possible, then please include:
The language of the open projects (C#, C++, etc.)
The kind of project (Console Application, ASP.NET, etc.)
Any extensions that are installed.
Most valuable feedback: For this case, the most valuable feedback is the set of steps to reproduce the issue along with sample source
code.
Unknown crashes
If you're not sure what's causing your crashes or they seem random,
then you can capture dumps locally each time Visual Studio crashes and
attach those to separate feedback items. To save dumps locally when
Visual Studio crashes, set the following registry entries:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe]
"DumpFolder"="C:\\Crashdumps"
"DumpCount"=dword:00000005
"DumpType"=dword:00000002
⚠️ Each dump file produced by this method will be up to 4 GB. in size. Make sure to set DumpFolder to a location with adequate
drive space or adjust the DumpCount appropriately.
Each time Visual Studio crashes, it will create a dump file
devenv.exe.[number].dmp file in the configured location.
Then, use Visual Studio's "Report a Problem..." feature. It will
allow you to attach the appropriate dump.
Locate the dump file for the crash you are reporting (look for a file with the correct Creation time)
If possible, zip the file (*.zip) to reduce its size before submitting feedback
Follow the steps in "How to Report a Problem", and attach the heap dump to a new feedback item.
⚠️ Do not attach heap dumps to existing feedback items. Please create a new feedback item for each heap dump you would like to
submit. If you were requested to provide a heap dump in order to
resolve a previous feedback item, simply reply to the request with a
link to the new feedback item where the heap dump is attached.
Most valuable feedback: For this case, the most valuable feedback is the heap dump captured at the time of the crash.
Please read it very carefully and in best case two or even tree times successively.
I hope it will help you and I wish you good luck!
As suggested with Dipen in another answer problem seems to be in Microsoft.CodeAnalysis try reinstalling nuget package for that & re-register in GAC if missing.
If Issue still exists, you can try disabling code analysis on your project like:
In Project in VS 2017, open References & right click on Analyzers and click on Open Active Rule Set like:
Uncheck all rules so that no code analysis is done on your project like:
3 .Save All files and now try rebuilding & run the project to see if issue is resolved.
The issue was an older JustMock version installed. Could only solve it with the help of the Roslyn team.
Recently Edit and Continue with VB.net has been kinda flaky.
In one project in particular. It was working as expected the last time I touched this project.
Recently when I pause the project while the winform message pump is running, I get a message saying no code is running. When I go back to my class file (in the same project, not external) I cannot make any changes - typing does nothing in the editor.
I have another class which is part of this solution, it has no entry point but I thought I would remind VS which was the startup project. This made edit and continue seem to work. I could make changes in the code, but when I continued the old version of the code was what was actually running. It's as if I am in an external class.
I just noticed something else, when you first start the project, edit and continue seems to work fine. After you continue, if you break the code again, it stops working.
I never had edit and continue problems at all with VS2012.
VS was hanging and crashing a lot yesterday so I rebooted my computer. That did not help this problem. I also installed SP1 and that did not fix anything.
I tried compiling to X86 and Any CPU.
Is there a setting I am missing? How can I get this working?
Thanks,
Brad
I tried a few more things based on some suggestion in other forums.
I repaired VS, I reinstalled VS, I tried to restore my default settings. None worked. I tried a simple project to duplicate the issue that I could share to get feedback. I could not get it to not work.
So assuming then the problem was with my project and not VS I made a new project and brought over my forms, modules and classes from project with the problem. I added my references and... edit and continue now works! The only things I changed from the default project were: Target CPU: x86, and Target Framework: .Net Framework 4
I still do not know if there was some corruption or it was a bad setting. This project was originally ported from VB6 many years ago and has been through a few VS upgrades as well.
I am using Visual Studio Ultimate. I have made a fairly long program which worked fine.
One day I find that the debug button was disabled and both the build and rebuild buttons do not work. I have tried opening the same project files in Visual Basic Express 2010 but still, the sane problem.
I don't really want to have to reinstall but I'm not even sure that that will fix the problem. Thanks in advance.
Is there a startup project? One project in the Solution Explorer should be in bold. Right-click the executable project and select "Set as StartUp Project". Additionally, open the Project Properties, Application tab, and ensure Application type is either "Windows Forms Applications" or "Console Application".
Did you try to reset the setting of your Visual Studio Ultimate?
Type: (In your visual studio command prompt)
devenv /resetsettings
Buttons disabled for just that program, or all programs?
I vaguely remember having a similar problem many years ago. Re-creating the project and solution files fixed it, I think (ie. create a new solution/project and import all the .vb files).
Another thing to check would be whether the compiled files have become read-only. Maybe VB.NET can't delete the old .EXEs
You need to build a test application. I think thats more difficult then making the application itself. In my personal opinion, your better off building the whole software in a notepad.
http://msdn.microsoft.com/en-us/library/ms182532.aspx
I'm working with VWD2010 and as stated in the topic title I have zero intellisense usability for my project.
I installed VWD2010 fresh a few months ago to start and noticed that intellisense wasn't working. For the last three months I was working with VS2010 trial and intellisense was working fine. The trial version expired, so now I am back to VWD2010.
Intellisense seems to work for NEW projects, so I created a new project and transferred all my files from the VS2010 project. Intellisense was working fine for a couple of days, but this morning I am back with it not working...
I have checked the following:
Intellisense works for new projects;
Intellisense is switched on in the editor settings;
I have reinstalled VWD2010 several times before without it making the blindest bit of difference;
I have reset settings both via the Options menu and via the command line, again without it making the slightest bit of difference.
Intellisense was definitely working for this project last Thursday evening when I last switched off my computer.
I have googled this issue several times and can't find the slightest bit of info on how intellisense is actually supposed to work. Advice generally resumes to "reinstall VWD" or "reset your settings"... Any help would be greatly appreciated.
Here is a distillation of some solutions that have worked for other users from the MSDN forum thread IntelliSense stopped working:
In Visual Studio, Go to Tools > Import and Export Settings,
and then select Reset all settings.
After closing Visual Studio, move the .suo file to a temporary
folder, and then reopen Visual Studio.
Check that Build Action property of your source files are set to
Compile rather than Content. Setting a file to Content detaches the source file from the rest of the project, disabling IntelliSense.
If you have a web project, exclude the WebConfig from the project and
rebuild the project. Then include the WebConfig.file again.
If you’re using C++, close Visual Studio, and then delete the .ncb
file. The ncb file contains IntelliSense information for C++. Deleting it resets IntelliSense, but it may take a while to rebuild in the background.
Finally, from the post Visual Studio & XAML – IntelliSense Not Working:
If you're using XAML, adding ;assembly= to the end of the custom CLR namespace fixes the issue.
I have a seemingly random problem where my project will run using an old version of a DLL file that no longer exists. Sometimes the real version of the DLL file will be used, other times an ancient version of the DLL file will be used. Who knows where Visual Studio is getting this DLL file from - it's months out of date!
I know that it is using the old DLL file, because when the application runs I start getting weird 'TypeLoadExceptions', complaining that methods don't exist or don't have implementations.
The following actions will sometimes help, sometimes not:
Restarting Visual Studio
Restarting the computer
Cleaning and rebuilding the solution
Deleting everything in \WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Searching for and deleting instances of the DLL file in \Documents and Settings\username\Local Settings\Temp
Sometimes I perform all of the above steps, and it still uses an old copy of the DLL file. Where is it hiding it?!
The same issue exists on our TeamCity server which is using MSBuild. When TeamCity tries to run unit tests it uses an old DLL file.
Now, I know that I can use assembly redirection in the web.config file, but the version number of the DLL file hasn't changed (I don't bother to update it, so it just stays at version 1). I don't want to have to start versioning the DLL files just to solve this problem. I would just like to know which particular caches I need to clear so that I can get on with developing.
It hides it in the GAC. There it may reside indefinitely. Using a more recent version may indeed solve the problem, but there is an outstanding bug in Visual Studio that has to do with choosing the correct version of DLL files. (If DLL Hell wasn't bad enough, the Visual Studio team is making it worse!)
Finding it in the GAC is tricky, and I cannot advise you on how to do that, but once the old version is deleted from there, it will not be found again. Sometimes, even though you are pointing the compiler at a newer version (by date), it will use the older version, because it has the same version level (by version). That is its bug.
Who knows where Visual Studio is getting this dll from - it's months
out of date!
The Modules Window is your friend...
It'll tell you exactly where that file is coming from. You can even use it with arbitrary processes if you attach the debugger.
I too would guess that they're hiding in the GAC.
You can look in 'C:\Windows\assembly' to see all the dlls and unregister yours from there.
The problem may exists with the build order or your projects.
If your Test project is built before the application project, this cause the behaviour you describe. To fix this: right click on your main project in VS and select the Project Dependencies... option and check the build order. Changes to the build subsequence can be made here by correctly setting these dependencies.
I had a similiar problem (but without Visual Studio). I am loading a .NET dll using UnsafeLoadFrom.
On one computer (a terminal server) the old file still remains being used, regardless of updated version numbers, etc.
The reason is simple: As long as a program instance is running, which has already loaded the old dll, the new dll will never be used. All further UnsafeLoadFrom will become the old dll although the old version doesn't exist on the harddisk anymore, because it has already loaded some time ago.
The solution is to shut down all running instances of the application or even restart the computer. Then all new instances will get the updated dll.
In my case, this was caused switching to Release mode, which had a different configuration (that used different location of the DLL).
In my case, I use Visual Studio to Publish Website, and though I check the reference of the dll file has changed, but the published dll still is old. Finally I new a Publish Web Profile and choose the right configuration (such as Debug - x86 / Release - Any CPU), publish again then the dll is corrected.
While this question is old, maybe someone will stumble upon it again in his/her quest for finding a solution.
In my case i got a CS0433 error for an ASP.Net page. After deleting the content in the obj\ and bin\ folders of the project, it worked again. Probably has to be done with a closed Visual Studio. Maybe also clean out those folders in referenced projects in the same solution (if used in the project and not pulled via Nuget).
In my case, the old DLL was in
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll
It DID NOT show up in c:\Windows\assembly.
I did a search of my drive for MyDLL, and it showed up as indicated above. I was debugging my test app at the time, and tried to delete the offending folder...no go...it was locked by Visual Studio. I had to stop debugging my app, close Visual Studio, and then delete the folder. Problem solved!! I don't know how my DLL got there, but it hasn't showed up there since I deleted it.
It's possible that the DLL is being referenced from another folder. It could even be on a network drive if you have one in your PATH environment variable. Here's how Windows searches for DLLs:
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx
In My Visual Studio 2015, I ensured that the offending Visual Studio project's Reference Path Listing is empty:
If you find such problem ,delete your Reference dll and pdb extensionfile add new references and rebuild your project .This often happens due to no rebuild of project,commit and updates.
The fix for me was making sure that the virtual directory in IIS was pointing to the correct directory. I have two projects on my system, a v4 and a v5. The virtual directory on my dev system was pointing to the v4 bin directory instead of my v5 bin directory - oops!
The file that was being cached in the dll, I couldn't trace the file, so I ended up renaming the file. This might not resolve the problem mentioned here but this was the fix that worked for me related to this question.
I tried a ton of things including re-installing VS 2107.
You can see where the DLL files are being loaded from in your Output window. After going through all mine looking for project DLL, I found it.
Clearing this worked for me.
C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'
I actually deleted all the files in:
C:\Users\YourUser\AppData\Local\assembly\
Holy Crow! I had an old, old suite of applications including 2 web services and a bunch of class libraries and a click once application. Well, click once stopped publishing for VS 2005 with a bunch of 'not found' errors. So, rather than hack away at my registry as suggested on this site, I figured it was time to upgrade the projects to 2017. Well, when I did this, the projects references in my web service projects got lost. Then, rather than helpfully just telling me that with errors, VS 2017 must have went to some cached file in C:\Users\XXX\AppData\Local\Temp\WebSitePublish or C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\8.0\ProjectAssemblies or C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root and 'helpfully' just used those files instead! I had to do a hardcore search with a custom program to find all the files on my C:\ drive and delete them before I finally got the errors!