I am using WCF in my project. The project was working fine before. Suddenly it has started throwing errors. I can build the project successfully but when I run it, a lot of first chance exceptions are being thrown. Most of them are related to microlib.dll.
A few AccessViolationException in System.Web.dll and WcfSvcHost.exe are also being thrown.
All other visual studio solutions are working fine except this one.
I have tried running the project in both Debug and release mode.
I have tried deleting IISExpress folder in Documents Directory
My VS solution contains many class liberaries and all are running in Any CPU configuration.
I cannot figure out the reason what is causing the issue. I checked the microlib.dll in C:/Windows/Microsoft.NET/assembly and saw it is last modified in January.
Can anyone please help me in this?
Related
I have multiple projects in a solution written in C#.
When trying to debug the code, I am attaching to the process of my application.
I am able to hit all the projects in the solution except few.
Everytime it says "The breakpoint will not currently be hit."
I tried all the approaches from the following link:
https://qawithexperts.com/article/asp-net/solving-error-the-breakpoint-will-not-currently-be-hit-in-vi/257
None of them worked.
Any other approaches I should check on? I am working on VisualStudio 2019 Enterprise edition.
I find that in this scenario you need to do a Build > Rebuild Solution in order to rebuild the project. You then Run Debug and attach to the process again
Currently I am developing a global exception handling in a .NET C# application. I get some strange behavior:
If I debug the application from Visual Studio (F5), an unhandled exception causes the main thread to be terminated.
If I start the application without Visual Studio (click on the .EXE) with the exact same compile output (DEBUG-Build), the App doesnt crash after an unhandled exception occured.
This is kind of weird behavior...Does anyone know what's going on here?
EDIT:
It seems as if something changes within the running code as soon as a debugger attaches to the process... If I start the App without Debugging from within VS, the App doesnt crash.
I’ve been doing some work with ASP.NET MVC but was having periodic issues with Visual Studio 2008 hanging (freezing / becoming unresponsive) when I tried to run my web application with debugging. The problem only occurred with a specific web project.
I tried deleting the Temporary ASP.NET Files (%userprofile%\AppData\Local\Temp\Temporary ASP.NET Files) but that did not solve the problem.
I tried deleting the obj folder. No luck.
I tried waiting it out one evening. I eventually feel asleep and when I awoke sometime in the middle of the night, my web app was happily waiting for input and Visual Studio debugging was completely responsive. That proved to be a temporary salve.
showallfiles The problem resurfaced again a few days later and I finally figured out the problem with my uncooperative debugger. I have a folder containing approximately 20,000 images that are not included in the Visual Studio web project but are sitting in a directory in the web site. I had turned on "Show All Files" in Solution Explorer to add some script files into the project. When "Show All Files" is off, F5 (Start Debugging) works like champ. When "Show All Files" is on, Visual Studio becomes unresponsive. In reality it is not "frozen" but simply taking a very long time to process those 20,000 image files.
Mystery solved.
I just changed to Visual Studio Community 2015 and I'm having a weird issue running a project. The project builds without any errors. But, when I go to start debugging I get the following error:
There is an error in web.config. Please correct before proceeding. (You might rename the current web.config and add a new one.)
This only happens if web.config is not open in the editor in Visual Studio. If I open web.config in Visual Studio and try to run the project, I am able to do so and no errors are reported.
Has anyone suggested that we close and reopen Visual Studio?
I had the same problem in a Web API project in VS Enterprise 2015. I knew there was nothing wrong with the Web.config file because, like you, all I had to do was to have it open before hitting F5. It went away after I removed and re-added the project to the solution during solution re-organizing. You might want to try that. No logics here but then the error seems illogical too.
I fixed/stopped the issue above and wanted to communicate what my fix was with the exact same symptoms as above. I had switched to a different published environment when this started happening (from UAT to Dev) and I commented out a section in the web.config file. Double checked to make sure I commented out the exact text. I even cleaned my solution and rebuilt it, same problem. Strangely, I could publish to the dev environment and the application would run (Web app with IIS 7).
The only difference between my local environment from when it was working and this problem was my web.config file. So I was thinking VS was having trouble accessing the file when not open in the IDE. I checked properties and the file had the appropriate settings. I then checked in the solution into our source code repository and the issue went away. We implement an SVN solution here.
Hope this helps.
I had Visual Studio 2010 installed on my Windows 7 desktop, that I was using primarily to debug ASP.NET solutions. Everything was working great, until one of the Windows updates installed a new version of the .NET Framework. Now I get the following message when I try to place a breakpoint and then do a "debugger step" in my C# code:
To make matters worse, it doesn't happen all the time. I tried to find any pattern, but the best way I can describe it is sporadic.
Any idea how to fix this?
I just got this in Visual Studio 2015. I was debugging on a separate thread, hit the breakpoint but could not continue. A reboot did not fix it.
I deleted all of my breakpoints, reset the two that I actually wanted and it works!
Can I suggest you try using the resharper test runner. I have also been hitting this error a lot in VS2017 15.5.2 I have found its something to do with the VS test system.
Even though this solution is a product recommendation (I don't work there) it solved my issue and I was able to get things debugged.
The problem I have run into twice now is that my program seems to be running code that no longer exists. I figure that some old version is stuck some how but have no idea how to get the compiler to run the updated code I've written.
The way I have spotted the problem is by observing that bit maps I've loaded keep getting drawn even after I've removed instructions to do so. The problem persists even after removing every reference to the image in question, content load lines included.
The first time this happened restarting the compiler didn't fix the problem but restarting the computer did. Now the problem has persisted after a full shutdown.
I m using ms C# 2008 express edition if that has any bearing.
My first thought would be that the build is failing and that Visual Studio is running the old version. I don't have VS 2008, but in VS 2010 the option to change this option is in Tools->Options->Projects and Solutions->Build and Run.
You have to figure out where the mismatch is coming from.
What happens when you run the .exe from outside VS? What about from inside VS? Can you verify that after a build, the binary you're executing has an updated timestamp? Is the stale code in a .dll where the new version isn't getting pulled in?
In my experience this happens when configuration profile is changed from debug. For instance if I am running the debug profile, it works. Then I change to the QA profile and make changes and then build the new assemblies. The assemblies are built to a directory called "QA" however, when I debug through visual studio it runs the code from the debug profile. I can remove references, recompile the code, visual studio will still run from the debug profile. It appears that none of the changes I made are in the code. When in reality I'm inadvertently running a old build.