How do I disable the background compiler for Visual Basic in Visual Studio 2008?
For my sins, I have to work on a large VB.NET project and it often locks up for 20 seconds at a time whilst doing the very helpful background compilation which is extremely frustrating.
I'd rather work blind between compiles and be able to do some work.
No there is no way to disable the background compiler.
Have you installed Visual Studio 2008 SP1. There were several bugs we fixed in the RTM version of VS 2008 which can cause the IDE to hang under certain circumstances.
We take issues with the background compiler very seriously. If you can give us a repro of the problem it will definitely be investigated. If you can produce such a repro or even send us a memory dump when the IDE is locked please file a bug on Connect: https://connect.microsoft.com/VisualStudio
A couple of other steps you can take. Do you have any Add-ins installed in VS? If so try uninstalling them 1 at a time. I've seen several cases where 3rd party add-ins caused lock ups in the IDE which were completely unrelated to the C#/VB framework.
Related
I have a home grown project (https://github.com/andybantly/MFC-Fractal) that I have been working on since the Visual Studio 2005/2008 days. I just recently put it in Git. Its home is on CodeProject.
I am not sure when this started (maybe 10 years ago...) but when I migrated my application to the latest version of Visual Studio, new/odd behavior injected itself into the code generation step. The IDE has somehow decided that when I build the source that I really wanted to build and run the source. This is somewhat annoying, especially during a batch rebuild all.
I am looking for helpful suggestions on configuring the IDE to prevent this behavior. It never used to do this out of the box.
Is it a show stopper? Absolutely not. Is it annoying? Depends on the side of bed I woke up on.
We are getting a application failed to initialize error 0xc000007b. I looked around it seems to maybe be the .NET framework, I also read a possible virus.
Our application is Visual Basic .NET 2010, running on Windows XP, Windows Update is turned on.
What fixes the problem, seems to be temporary, is take my backup copy of the .exe and replace the .exe on the machine, it runs for a few hours. Keep in mind I am 12 hours away or more from the machine, I remote to it using TeamViewer.
Will event viewer or something else give me a better idea of what happened? or more information about the error and it's cause?
I'm far from a Visual Basic guru, so I'm very puzzled as to why this application is throwing this error after running for approximately 2 years.
Can windows update cause this? Does .NET framework update itself automatically?
Thanks for any help.
Well if your program was not recompiled, I'd doubt it's the program itself, but if you have the source code you can try running it through the debugger to see what's going on, and where. Personally I'd try just reimaging your xp system and seeing if that fixes the issue.
Also, isn't xp out of support? I suppose windows updates could affect it. I've seen updates cause older applications to break, so it is a possibility. You can look at the recent updates and roll them back.
Are there any tools which i can use to diagnose performance issues with VisualStudio 2013 Premium edition?
I'm currently running the Update2 RC (however speed has been the same prior also). and have a few extensions running
Web Essentials for Update 2 RC
Rename Visual Studio Window Title
Productivity power tools
nunit test adapter
ReadyRoll.
On an Intel Xeon E3-1220 V2 3.10GHz, machine with 8G of RAM i frequently experience performance issues which seem out of character to the resource available to Visual Studio.
The example scenario is a webforms project in a solution which references 19 other library projects, which is controlled by an in house TFS2012. Browser link is disabled, and the solution is built and deployed against the local IIS rather than IISexpress etc.
having two instances of visual studio open which have versions of the solution from different branches appears to have a large impact on performance.
switching between two instances of Visual studio can often cause a hanging state for a minute.
pasting code(even a small paragraph) ontop of code in an existing file (aspx,.vb) can cause a minute or so hang.
You did check out this page? it contains some tips from microsoft for troubleshooting performance.
You could also use i.e. process monitor from sysinternals to check what VS is actually doing in regards to file and registry access.
Another tip could be to delete this C:\Users\\AppData\Local\Temp\Temporary ASP.NET Files\
I have written dozens of custom code analysis rules. The rules were developed targeting Visual Studio 2010. As required, the assembly has a reference to version 10.0 of FxCopSdk, Microsoft.Cci, and Microsoft.VisualStudio.CodeAnalysis. They run correctly in Visual Studio 2010 and build properly in TFS 2010.
I'd like to migrate to Visual Studio 2012. When I run the custom rules on an existing solution using VS 2012, however, I get CA0062 errors. The root cause is a CA0053 error loading the custom rules assembly. I understand that these references to the three assemblies need to be updated to version 11 for Visual Studio 2012. This can be done using version redirects in config files. I can get this to work locally by redirecting the Visual Studio 2012 IDE and FxCopCmd binaries, but am running into trouble when checking code into TFS 2010.
There are two apparent solutions we have considered, but neither is very palatable. The first is to require each developer to redirect locally, and then modify the TFS build agents to redirect as well. The second is to maintain two branches of the custom code analysis rules, one targeting version 10 (VS2010) and the other targeting version 11 (VS2012).
Is there a better way to do this, or do we need to all upgrade to TFS 2012 and Visual Studio 2012 simultaneously?
You can try to manually edit the project file and write two include blocks (one for VS2010 and one for VS2012), then define conditions to use the correct one. You only have to somehow determine if You want to build for VS2010 or VS2012 in msbuild.
Between your approaches and the one proposed by ZFE, you pretty much have all the potential candidates. Given the choices, I would strongly recommend branching since there is no official SDK for FxCop with backward-compatibility guarantees.
If you're lucky, you won't hit any behavioural or API surface changes that affect your rules, and the only difference between your two branches will be the references, so any merges will be trivial. However, any time investment you make in an alternate approach now will be lost if you need to branch later, and the likelihood of eventually needing to branch is non-negligeable.
Running VS2003/05 under Vista makes the former screw up the display at least 50% of the time - you start debugging, VS kicks in and you see the windows/docking panes screwed up, not refreshing, etc... I've contacted Microsoft about this, but they weren't much help, I was wondering if someone knows any fixes?
I'm running VS with visual styles turned off under Vista, so that it doesn't hang when you try to do a "find in files".
All the latest updates/service packs are installed.
For Visual Studio 2005 , install the
Microsoft® Visual Studio® 2005 Service Pack 1
and the
Visual Studio 2005 Service Pack 1 Update for Windows Vista
Take a look at the Visual Studio .NET 2003 on Windows Vista Issue List and see if you find something there.
And see if that help things.
I've done a lot with Visual Studio 2005 Express on Vista, and have never seen any display issues.
Vista is pretty sensitive to the quality of the video drivers - have you tried updating yours?