I have a solution with several projects that have Register for COM Interop checked.
I have a Visual Basic 6 project that references the resulting TLBs. One issue with VB6 is when it references a dll/tlb, it puts a lock on that file.
Using Visual Studio 2010, unless I'm doing a rebuild or have made a change to one of these interop projects, I can build/run the solution (with the VB6 project open) without it barking that one or more of the assemblies is locked.
However, using Visual Studio 2012, even on a simple build where nothing has changed, apparently it always does the regasm, which makes it impossible for me to debug my VB6 project.
Is this new feature of Visual Studio of running regasm on build something that I can turn off?
EDIT: Allow me to simplify:
Using Visual Studio 2010, I hit Build-->Build Solution and check the output for one of my assemblies that is marked as Register for COM Interop and the file has not changed.
Using Visual Studio 2012, I do Build-->Build Solution and check the same assembly, it has been updated, and does so every time I hit Build Solution.
I want the behavior in Visual Studio 2012 to work the same as it did in 2010.
EDIT (again):
I posted this to Microsoft Connect. If someone answers it there or posts a workaround, I'll urge them to also post the answer here.
I've always encountered problems like this when running VB6 and VS20XX, but I always did a rebuild. My suggestion is to stop using VB6 for testing purposes. I found it was far easier to simply create a testing project and do all of my testing in .NET on my .NET code. This should only require a small amount of set up, but it is well worth it in my opinion.
I know this isn't an answer to your specific question, but it offers an alternative. As far as the problem you are describing, I can't duplicate a change in behavior. I start off with only VS201X open, full solution rebuild, open VB6 and add a reference to an exposed COM DLL. I didn't notice anything unexpected.
Build works fine as long as I haven't changed anything in the COM DLL
Build fails if I changed the COM DLL's code as the file is locked
Rebuild fails as the file is locked
Related
Relates to Error while using Qt in Visual Studio 2019
I have the same error. Unfortunately I cannot still fix it, as Qt VS Tools for VS 2015 aren't updated. But my question is not how to avoid background build.
My question: what is background build?
Oh, I believe you are running into the 32767 names for this.
Let me preface this by stating that 2015 may have been the last time I used Visual Studio or developed anything for a Microsoft platform.
Part of your answer is in this discussion.
I believe the latest (or more current) name for "background build" is "live code compilation."
This is a resource robbing, highly annoying, syntax checking thing Microsoft thought would be great. It ranks right up there with Microsoft Clippy as far as tragic ideas go.
Basically, as you type, visual studio tries to build your stuff, puts squiggles under errors and generally consumes a whole lot of resources.
If you are using that Qt plug-in to build a QMake project this can cause all kinds of hardship, especially when you have UI files that need to MOC compile and are in the designer modifying the .UI file.
Whatever version of Visual Studio I was forced to use for that project, the first thing I did was find out how to turn that off.
Qt appears to not play well with Visual Studio it seems.
Here is a more complete description if you happen to have the plug-in.
BuildOnSave is an extension for Visual Studio 2019 and 2017 that
builds the current solution as soon a file is saved, and in
combination with the the extension SaveAllTheTime, enables a live,
background build experience while you type.
My company recently created a Visual Studio 2010 add-in that allows us to create LINT files from any given visual studio project from 2010, 2008 and 2005. We now want to get this same add-in to work in Visual Studio 2012, because we know that many of our customers will be using this in the near future, if not already.
We thought that it should be a simple "switch-in", and that the same code should work for both, but lo and behold, the VS10 add-in didn't work in VS12. So I copied the code (absolutely no changes) into a VS12 add-in, and surprise surpise, it did work. Naturally, we do not want to have two versions of the same code; bad for readability, bad for maintainability, so we still want to find a way to get the VS10 add-in to work in VS12.
I think the problem lies in the Microsoft.VisualStudio.VCProjectEngine assembly. This is interpreted differently in VS12 to how it was in VS10, meaning that when VS12 reads the add-in, it doesn't do what we want it to do.
I have done some research into this problem, and many people suggest creating a work around by using reflection, but I am reasonably new to this concept and don't feel confident enough to try it and risk seriously ruining the add-in.
So my question is this: Is there a nice and easy way of being able to read the VS10 version of the Microsoft.VisualStudio.VCProjectEngine into VS12?
Much appreciated :)
I later found an answer to this question and realised it hadn't been confirmed on the thread.
The answer indeed lies in the VCProjectEngine assembly. For some reason, this is a different module in Visual Studio 2010 to the module (with the same name) in Visual Studio 2012, which means any code requiring the module when written in VS2012 will not work in VS2010 and visa-versa.
It's a pain, because it means we have two lots of exactly the same code, but that is the way it has to be.
I have been trying using Pex in a F# project but I have faced several issues on which I would appreciate some help:
Visual Studio Pex addin worked for half an hour and not for complex project exploration.
After that each time I run a Pex Exploration from within Visual Studio 2010 I get a !warning! [metadata] no explorations found after applying all filters; did you forget a [PexClass] or [PexMethod] attribute? error message. If I copy and paste the command run by visual studio when doing the exploration and remove some attributes (like sourceFilter ...) and run it from a command console then I get some generated tests. Any idea why visual studio generates an invalid command?
After a while the Microsoft.Pex.Framework.dll either disappears from the .Net Reference list and I have to reference it manually using its file path or I can't even reference it any more and I have to uninstall/reinstall Pex. (A reference to C:\Program Files (x86)\Microsoft Moles\PublicAssemblie\Microsoft.Pex.Framework.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.)
All these issues don't occur when I work on a C# project.
Issues 1 2 3 occurred with the Academic version.
Using the version available for MSDN Subscriber I never got it working within visual studio (Visual Studio 2010 Ultimate NO SP1). However it worked from the command prompt. I did not face problem 3 with this version.
Has anyone managed to get Pex working with F# within visual studio ? If yes can you you tell me how you did it ? Which versions (VS and Pex) do you use ?
I have had some success running Pex with F#. The version I used, if I believe my Downloads folder, was the academic version of Microsoft Pex and Moles 0.94.51006.1 Release for (x86). The installation file was named pex.academic.x86.msi.
I don't know if that version predates yours.
My impressions from my trials were that Pex and F# were not a very good combination: Pex insisted on creating test cases with null inputs. As generating null values in F# isn't all that common, that's typically not the scenarios in which I'm interested. Adding lots of assumptions to eliminate those just left me with Pex not being able to generate test cases. Admittedly, the functions I was testing were too complex, I still like the idea behind Pex and might try it again on smaller/easier pieces of code.
Using Pex and its GUI inside VS 2010 worked relatively fine, but not without frustration.
I have a periodically occurring problem when building with Visual Studio 2010.
Sometimes it refuses to build with an error message like:
Error 102 Unable to copy file "xxxxx\Debug\Services.dll" to "bin\Debug\Services.dll". The process cannot access the file 'bin\Debug\Services.dll' because it is being used by another process.
The only remedy I have found is to restart Visual Studio. Closing the solution is not enough.
I have tried to find the culprit with Process Explorer since I suspected that one of my own threads didn't close down as it should. However the process is devenv.exe, i.e. Visual Studio itself. Also I get this symptom only with VS 2010 even when building upgraded VS 2008 projects. I never experienced this problem with the same projects under VS 2008.
I have a lot of custom made WPF user controls and I have a theory that it is the WPF designer that sometimes hold on to the control's dependent dll's when it should be releasing them for a build. The theory is not well established since this is a periodic problem and sometimes it occurs without the designed being open. I also have the same problem for a windows forms project. Sometimes I get through a day without a locked dll. Sometimes it is every other build or so.
I have asked Microsoft about the problem and they told me to make a dump of Visual Studio and debug the dump. I didn't find that to be sound advice.
Have anybody experienced something similar? It is really annoying.
Update 1
Since this appears to be a Visual Studio bug and Microsoft has responded that they do not intend to do anything about it I would like to encourage everybody who works with custom user controls to up-vote this bug at connect.microsoft.com.
The bug is both reported here: https://connect.microsoft.com/VisualStudio/feedback/details/587281 and by me here https://connect.microsoft.com/VisualStudio/feedback/details/568672
Update 2
I have hacked together a simple Visual Studio macro that closes down all .XAML files before building. So far I have not experienced the lockup with this macro.
Add the following macro in Visual Studio and assigned to your favorite build short cut. Maybe / maybe not that will fix the problem.
Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports EnvDTE90a
Imports EnvDTE100
Imports System.Diagnostics
Public Module CloseXamlAndBuildModule
Sub CloseXamlAndBuild()
For Each myDocument As EnvDTE.Document In DTE.Documents
If myDocument.Name.EndsWith(".xaml") Then
myDocument.Close()
End If
Next
DTE.Solution.SolutionBuild.Build()
End Sub
End Module
I finally found a stable working solution. I realized that the source of the problems were initializing code in the constructors of WCF services and WPF controls. After cleaning the constructors from any dependencies to other assemblies everything has been fine.
Try using VSCommands plugin.
It has option to 'Apply Fix' that will allow you to close any process which keeps the file locked (most often than not it is vshost process which can be killed).
This is a fairly persistent complaint about VS2010 although it is not wide-spread. I haven't seen a good diagnosis for it yet. The feedback item to watch is this one, it seems to be the collector for most duplicates. Getting it resolved quicker probably is going to require opening a case at Microsoft Support.
I actually reported this problem to Microsoft Connect a while ago, but had not checked up on the issue in a while.
My original report to Microsoft is here.
Among the comments is a way to reproduce the issue with custom user controls (as I suspected).
Microsoft just replied with a standard "thank you for your feedback, your suggestion does not meet the criteria to be addressed". Thank you Microsoft. I guess I will just have to live with restarting Visual Studio a couple of times every hour.
I’m using visual studio 2008 and moles version 0.93. Everything works well except when I try to debug any test that uses a Moled type. The test skips all my breakpoints. And I get the following message in the output window:
Unable to attach. Check for one of the following.
The application you are trying to debug uses a version of the Microsoft .NET Framework that is not supported by the debugger.
The debugger has made an incorrect assumption about the Microsoft .NET Framework version your application is going to use.
The Microsoft .NET Framework version specified by you for debugging is incorrect
Please see the Visual Studio .NET debugger documentation for correctly specifying the Microsoft .NET Framework version your application is going to use for debugging.
If I try debbuger.Break () I get a message: "No symbols are loaded for any call stack frame. The source code cannot be displayed."
I’m in a crunch right now chasing an issue with one our main components and it has been a pain (like I need novocaine) trying to figure anything out without being able to step through the code.
I want to take advantage of mole's "smooth debugging experience". However, I can't seem to get the debugger to attach at all.
Thanks,
Bzz
See the solution to this issue here:
http://social.msdn.microsoft.com/Forums/en/pex/thread/91c08bf4-3260-458c-a221-91f030a75499
I had this problem when I moved a project from Visual Studio 2010 to Visual Studio 2008. Here's what I did to fix it.
Close Visual Studio. Navigate to the Debug/bin location. Delete the following files:
*.vshost.exe
*.vshost.exe.config
*.vshost.exe.manifest
Open the solution. Goto the project Settings. Under the Application Target Framework, select a framework lower than the one you are working with (you'll set it back later). Visual Studio will close and re-open your project automatically. Then set the Target Framework back to the original version you were working with. Rebuild all, and debugging will work properly.