I have a command line app that uses a certain assembly. The assembly is sitting in the root of the project, and set to "Copy Always."
I add a reference to that assembly, and Visual Studio 2010 is happy -- Intellisense highlights everything correctly, and no errors are reported.
But as soon as I actually build, I get compilation errors like I haven't added the reference, and Intellisense suddenly gives me red squigglies as if the reference was never added.
But the reference is still there.
If I delete the reference and then re-add it, Visual Studio gets happy again, and the red squigglies go away. Then I build, and the same thing happens again.
So, Visual Studio agrees that the reference is there. Until I build. Then it claims its not. Even though it is.
And this only happens with a specific DLL (NLog, if it matters). Another DLL (HtmlAgilityPack) works fine, and it's set up and configured the exact same way.
With a little search I found a problem with the .NET client profile. Try looking at that link and see if it resolves the issue.
There's also some posts on it at the microsoft connect website if you're interested in further reading.
Related
I don't know when this started, but I discovered that Visual Studio 2013 Update 5 aborts when attempting to open properties for a project within a solution. It seems to only happen when we have more than one project in the solution.
I've been able to reproduce it in two circumstances:
The first project is C++ and the second project is Fortran. Right-clicking on the first project and selecting Properties crashes Visual Studio without a crash dump or any kind of pop-up notification. Visual Studio just ceases to exist. Right-clicking on the Fortran project brings up the property sheet without any problem.
The second circumstance is with two projects, both C++. In this case, I'm able to open properties successfully for the first project, but not for the second one.
In every case I've tried where there's a one-to-one solution and project, it's working fine. A colleague who's working with VS 2013 Update 4 verified that the crash occurs for him as well.
We don't know when this started, but historically, we've opened these property sheets many, many times. However, it's probably been a few months since I've worked on a mixed-language process, and same with my colleague.
I've turned on logging and there was a complaint in the log about two versions of the Desktop SDK having the same internal ID. I removed one of those altogether, but that didn't seem to affect anything. It's also not clear if that error has any relationship to the crash.
I've also done a repair on Visual Studio, and that did not correct the problem.
I've also tried deleting the .suo and .user files. Again, no luck.
I've done quite a bit of googling but haven't found anything that matches this specific problem.
Any ideas?
Thank you,
Doug
We have recently upgraded an MFC solution from Visual Studio 2005 to Visual Studio 2013 (Update 4), at last. I think the solution originates in Visual Studio 6 and was upgraded to VS2003, then VS2005. It is a Multibyte (i.e. non Unicode) solution.
We haven't had many problems, so far. In fact it seemed like we had sorted pretty much everything out.
One of the errors we were getting was in the rc file, where the compiler said it couldn't find "l.esp\afxres.rc". Upon investigating the issue, we found that in VS2013 (I guess 2012 and 2010 too) the path is "l.esn\afxres.rc" so we changed it, and it all worked fine again.
Now, after "finishing" the port, we've continued the development, and we've found that, every time we make a change to the resources (add new controls, change the properties of existing ones) the path returns to the old one ("l.esp\afxres.rc"). It changes it when saving the resource file (make change, click save, it's already changed).
I guess there is some property, or something, that it's still telling the IDE it is a Visual Studio 2005 project, but I can't find it. I've tried removing the UpgradeFromVC71 property page, but to no avail.
Any ideas?
Ok, I've found it! Leaving an answer for future reference.
It's in the Resource include files. Go to Resource View, right click on the .rc file and select "Rsource Include Files". There are the offending includes. Change the path, and done!
https://support.microsoft.com/en-us/kb/198536 (old, but good enough)
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
I updated the Visual Studio Developer tools and voila! Some of my code no longer functions. I can debug, but 90% of the fixes I had made in the past day disapears whenever I debug. It worked earlier today with the old Visual Studio; but now, the effects of the code simply don't show up when I debug.
I can see the code in the code-editing window, but it doesn't debug any way I try. Does anybody know how I can fix this?
P.S. If this belongs on SuperUser, I'll be happy to put it there. Simply tell me, and I'll move it.
Manually clean the solution and output folders (by deleting the obj and bin folders while Studio is closed). Re-open and rebuild. If it's in a referenced DLL, drop the reference in the consumer, build to get a failure, then re-add.
I have the following problem with design-time debugging in Visual Studio 2010 Pro.
In my solution I have got two libraries. One with name Alfa that contains some of my basic components. Two with name AlfaDesign that it contains designers for components from library Alfa. And of course I have a project for developing and testing Alfa components.
AlfaDesign is having reference to Alfa library. And the test project is having a reference to Alfa and AlfaDesign.
And my problem:
When I put breakpoint in component's constructor from the Alfa library and then I put this component on the form in my testing project, the debbuger is doesn't break. Visual Studio is still running.
I followed instruction from the tutorial Walkthrough: Debugging Custom Windows Forms Controls at Design Time, but without any success.
I ran into this problem today with one of my projects, and I spent the last several hours figuring it out. What I found is that the symbols and modules will not load when your project target framework is set to anything less than .NET 4 when doing an F5 debug. Switching the projects to .NET 4 does fix this weird behavior, but you may not want this for .NET 2 applications that you don't want to use the newer runtimes/BCL.
However, you can still correct this behavior. You can run manually use Debug -> Attach To Process and select devenv.exe and that will load the modules and symbols. So, you can either have a second instance of Visual Studio 2010 already open and simply attach, or you can run it on debug (Run External Program), Detach, and Re-attach to get the modules to load.
I thought this was something wrong with my environment settings, because my install of Visual Studio is very customized, so I thought there might have been some sort of setting, conflict, or file difference, but it seems to just be a weird behavior in the Visual Studio 2010 debugger. I would be curious to see if anyone from the Visual Studio 2010 team could investigate this a bit further.
If the breakpoints are properly resolved, then it must hit properly.
Please check the following.
Is the breakpoint resolved properly or not. If it's properly resolved, it will be displayed in red during debugging sessions. Otherwise the red will turn into a disabled state (with a yellow exclamation mark with a grayed circle).
Why don't you put a breakpoint where the object is being constructed and debug through it? So that you can ensure that your construction code is working well. You can step through (F11) to get inside the constructor.