Surely the answer will be "you can't" or "use XP mode", but I'd like to know if it it possible.
The issue I have is that whenever I debug some application and hit a breakpoint, when I stop the debugger the debuggee remains stuck. It can't be killed, I can't attach another debugger (it says it is already being debugged). It won't go away until I close Visual C++.
This is hapenning on a Windows 7 64 bits install. VC has SP 6 installed.
My previous fix was horrible.
Finally, I developped a new fix, working perfectly with the english version of Visual Studio 6. (SP6 I think)
You need to check the version of the file DM.dll located into "Common/MSDev98/Bin"
The correct version is 6.0.9782.0.
link: http://www.dr-hoiby.com/TLLOC.dll (28KB)
how to install: replace "Common/MSDev98/Bin/TLLOC.dll" by the version downloaded.
Best regards.
Comment reposted:
You can try using Visual Studio 2008 with VC6 compiler. I recently blogged about this.
I developped a little fix for that.
You just have to copy the file "ShiftF5Fix.dll" into "Common/MSDev98/AddIns/" et load it from Visual.
It's an hugly fix.
If you modify your source file during debugging you have you answer "NO" to the poup displayed after you press "SHIFT+F5" to stop the process.
link : http://www.dr-hoiby.com/ShiftF5Fix.dll
Best regards
Another option would be to install daffodil.
This is an open source project to compile all versions of visual studio in VS2010.
Once this is configured you can use visual studio 2010 debugger to debug VC6 projects.
On the heels of Dr Holby, I implemented a leaner variant, with source code:
http://www.algonet.se/~tamlin/TLLOC_fixer.zip
The code currently only understands sp4 (?) and SP6, but I think it'll cover most cases.
You only need to compile the source (1.cpp, 1.rc), rename your existing TLLOC.DLL (which btw stands for Transport Layer Local - as opposed to remote debugging) to TLLOC.old.dll, and drop in the one you compiled (~4KB). Should work like a charm for all 32-bit debugging needs, from Windows 95 to Windows 7 (and later).
Related
I am working on a c# code for the last couple of weeks and I debug it very often.
VS 2019 was working properly but suddenly it got very slow and laggy when I tried to debug my code.
I checked all resources on my machine. All seem as before and are available enough.
Even I checked the same IDE with other codes. All runs and debugs fast enough as before.
I also updated my IDE to the last version (currently 16.8.5 by the end of February 2021).
Did anybody has the same experience with the VS2019 ever?
Thanks in advance.
Not sure whether the issue is caused your code with IDE environment together. Please try the following suggestions:
1) disable any third party installed extensions under Extensions-->Manage Extensions-->Installed to check whether an extension caused that.
2) reset settings under Tools-->Import and Export Settings-->Reset all settings and you can also make a backup of the settings
3) close VS, delete all files under C:\Users\xxx\AppData\Local\Microsoft\VisualStudio\16.0_xxx\ComponentModelCache
and also delete .vs hidden folder under your solution folder, bin and obj folder.
4) type devenv /safemode under Developer Command Prompt for VS to start a pure VS and then try your project.
5) create a new project with your same code and check if this works.
Besides, if all do not help, you could try a small reproducible sample with us.
If debugging suddenly becomes slow, you might consider checking your symbol settings and debugging settings. If you for example enable .NET framework source stepping, debugging can be slow, or if you do not cache symbols or disable for example Just My Code or enable other stuff, like IntelliTrace or install a bad extension.
It might not be an alternative for you, but I am pleased to inform you that I have been using Visual Studio 2022 and it is radically faster. Yes, this is not opinionated, this is an observation. It IS faster. Maybe it is because I do not have many extensions on it, but it is also a 64-bit application with less memory pressure on the GC. So you can first check your settings and then give VS 2022 Preview versions for a spin. I have used it for months and the amount of bugs are rather small if you do typically development. For a Preview version, I am impressed with what they are working for nextgen Visual Studio.
You should also clean your solution and delete and bin and obj folders via for example Powershell script to make sure your binaries are updated. Then rebuild.
If you have "live share" extension enabled, perhaps can try to disable / uninstall that. This one was causing my problem.
Ok, #Mr Qian no 3 did the trick for me.
Situation: After a "Cleanup" (Microsoft Visual Studio\Installer\InstallCleanup.exe) my VS2019 was partially gone. Good tool. :-(
After (re)install, I had 2 folders "ComponentModelCache" over 2 folders of 16.0_xxx : 16.0_4f678462 and 16.0_119826cb
I renamed both "ComponentModelCache" folders (you can delete later, when it has effect)
Build ran as never before...
Thank you, Mr Qian
My problems started as I upgraded to Visual Studio 2022 (from 2019) and upgraded to Windows 11 (naughty naughty, two major changes).
Turns out Windows Defender didn't preserve my exceptions. Using this PowerShell script as a template saved a bit of time:
https://gist.github.com/Braytiner/be2497d1a06f5a9d943dc7760693d460
Performance is back to where is was pre my Windows 11/Visual Studio 2022 upgrade.
Visual studio 2019 (16.8.5) has this problem in debugging. I have updated it into 16.11.8 and it works properly.
I recently installed Visual Studio 2013 Ultimate version on my machine. I'm just trying to create a sample windows form project and trying to open the designer / form by double clicking on Form1.cs and I'm getting this weird error message:
"the service microsoft.visualstudio.shell.interop.iselectioncontainer already exists in the service container"
My system is already having Visual Studio 2010 which is working smoothly from a long time. I then installed Visual Studio 2012 which was giving the same problem as above. So I went ahead with installing VS 2013 hoping that I might be able to get rid of this issue, but no use.
Once I click OK on the error windows, I can see the following "message" in the bottom Error List window:
"The file 'C:\Users\ABCD\Documents\Visual Studio 2013\Projects\WebSite1\WindowsFormsApplication1\Form1.cs' does not support code parsing or generation because it is not contained within a project that supports code."
I have spent 2-3 days searching various blogs like these, all of which talk about previous version of Visual Studio like VS 2005 / VS 2008:
https://connect.microsoft.com/VisualStudio/feedback/details/311949/the-service-microsoft-visualstudio-shell-interop-iselectioncontainer-already-exists-in-the-service-container
Form inheritance in Visual Studio 2008 doesn't work
I have even tried uninstalling and reinstalling VS 2013, again no use.
It would be really great if someone can help me out in fixing this.
I've just had the exact same error message.
After compiling the solution(F6 or Build->Build Solution) it worked fine for me.
To deal with your issue, please first make sure that you installed latest updates on your Windows 8 machine, and then repair VS2013.
During your repairing process, please temporally turn off your anti-virus/antispyware software and repair VS2013 with the Administrator privilege.
follow this link
The problem got resolved finally, after so many days and various frustrating tries to resolve the issue. I should thank Tim Atkins from Microsoft for helping me with resolving this issue.
Fix: When we tried 'gacutil /l system.design', we found that there were 3 variants of system.design; One from .Net 2.0 targetting MSIL, second from .Net 4.0 targetting x86 and last one also from .Net 4.0, but targetting MSIL.
On a working machine, there were only 2 entries, the .Net 4.0 one targetting x86 wasn't there. Hence we uninstalled this version using gacutil which did the magic. I was so relieved seeing the win forms popping up without any errors anymore :)
I changed the target framework from 4.5 to 4.6.1 and it fixed it for me. My assumption is sometimes when you change target framework back and forth and the process does not go through all the way (cancelling in the middle of changing it) - something happens that leads to this error. Hope that helps
I solved this be closing VS, deleting contents of the .vs folder where my solution is, restarting VS and recompiling.
Seems like one of those file/settings/caching problems that pop up now and then, might be after switching source branch.
VS2019, .net fw 4.6.2.
If your C drive (Where you are installing Visual Studio) does not have enough space, try moving some files from the C drive to another drives.
I have Visual Studio 2010 Ultimate on Windows 7 Enterprise running on a x86 box. I cannot create any C++ project from VS although I can create C# project. On the new project dialog I press OK button and nothing happens. I don't get any error but no solution or project is created either. Not sure if it helps but I log in as Administrator. Any ideas?
Did you check the thing called C++ runtimes which is required by VS to run properly?
I guess the idea to reinstall is good.
This will even repair some missing or corrupt which may have been accidentally deleted or corrupted.
Most probably you did not check the C++ language option during installation. If you re-run the Visual Studio installer and check the C++ language option (maybe choose custom setup to make sure you see the option and are able to include it), everything will run file.
In case you already did that, there might be a problem with the C++ project type registration in VS. Please come back to this forum if you still have problems after re-installation.
Following my last question (see: Problem in hosting ActiveX on Vista (in a Visual Studio 6 C++ application)) I ran into a strange problem. I hope this’ll be a simpler issue to the experts here:
Each time I run certain application like iexplorer or firefox, the Visual Studio 6 suddenly opens up in debug mode with a message “User breakpoint called from code at 0xSOMETHING”.
I can press F5 to continue but the applications run slowly and needless to say I have no wish to debug these applications…
My guess is that when I worked on my VC++ application I placed breakpoints at windows methods like CAxDialogImpl::Create(), AtlAxCreateDialogA() etc’, and for some reason it was kept somewhere.
Of course I now removed all the breakpoints and re-compiled the project but still this keeps happening!
I checked in the tools->options but the “Just-in–time debugging” is not marked.
Any idea?
(I use Visual Studio 6 which I installed on Vista)
Thanks a lot,
Erik
Not sure this helps but anyways:
Try disbaling the default debugger option. (It says Dr. Watson but it depends what you have set as the default debugger)
http://www.bridgetonova.com/2007/09/how-to-disableenable-windows-default.html
Also as per this post Visual Studio 6 is not supported on Vista. Only Visual Basic is.
http://www.itwriting.com/blog/167-visual-studio-6-on-vista.html
You should probably re-ensure yourself that you have removed all calls to DebugBreak() and manual break-points. Also try to ensure that when you recompile you re-register everything to point to the right places (i.e. the activex pointed to by the guid in the registry is actually the latest recompile).
Yes, I know... I could set up a virtual machine running XP. Unfortunately our build environment is such that we need to be running VC2003, 2005 and 2008 concurrently and it would be much more convenient if I could run 2003 natively on Windows 7 for the few projects we have that require it.
I realize some things may not be available in the IDE, but I was able to run 2003 under windows Vista and if I could get the same base level of functionality under Windows 7 I would be extremely happy.
Right now I get an error opening the *.pdb file when I compile after switching vc2003 to run as Administrator under compatibility mode for XP SP 2.
Thanks!
Give XP Mode a try if you can't get it to run natively.
http://www.microsoft.com/windows/virtual-pc/download.aspx
I wrote a blog entry about this a while back that you can check out - http://technikhil.wordpress.com/2010/01/12/visual-studio-2003-and-windows-7-can-get-along-really/
The only thing I am stuck on right now is the global search functionality of VS 2003 - it hangs the application. My workaround is to use windows 7 search :-). Other than that - so far so good...
Update: I got the search to work as well by disabling the Aero functionality - I have updated my blog post with the details...
(Much of this repeats what's already been written above.)
I need to run VS2003 as adminstrator under Win7 64-bit, to support legacy projects (e.g. those that run on the original Xbox). The old XDK requires VS2003, so upgrading is not an option. I could run WinXP but I prefer Win7.
VS2003 is not officially supported under Win7 and trying to do so creates a couple of fairly annoying problems:
Find-in-files causes VS2003 to hang.
Linking fails due to a PDB file handle leak.
The Find-in-files hang is solved by using "Disable visual themes". Navigate to the VS2003 shortcut (Start-->Microsoft Visual Studio .NET 2003), right-click to get context menu, select Compatibility tab, Settings pane, and check "Disable visual themes".
The linker failure (LNK1201) happens when you run the program through the debugger, stop it, modify a file and build. The error is that a Visual Studio hold a handle to the PDB file, while the linker tries to write to that file. You can stop and restart VS2003 to bypass the issue. Works but is annoying.
You can also use the Microsoft SysInternals "handle.exe" utility to find, then close handles held by a process on a particular file. Write a script to call handle.exe and set up the VS2003 project to run that script as a Pre-Build Event. (See this thread.) But handle.exe requires running as admin.
You could hypothetically change handle.exe to run as admin using the usual steps (e.g. as a compatibility setting) but then handle.exe (apparently) runs in a nested shell, and then the stdout text does not get to the calling script.
You can make VS2003 run as admin, in which case the Pre-Build script also runs as admin, hence does handle.exe, and that works.
The remaining trick is to get VS2003 SLN files to open properly. If you simply make VS2003 run as admin automatically then the VS version selector fails to run VS2003. I don't know why, but it is the case.
You could associate SLN files to open using VS2003 devenv.exe instead of VSLauncher.exe. That works but then all new SLN files (2005, 2008, 2010, 2012, ...) fail to open.
So the final step then is to make VSLauncher.exe run as admin. This fails as of KB2492386 as this thread indicates. Uninstalling that update was the final step in this saga, to get everything to work.
PATCH NOW AVAILABLE
After some reverse-engineering, I found the incorrectly refcounted COM object responsible for the leak (it was off by 1) and developed a stable patch and corresponding article describing the fix. This addresses problems encountered while using Windows 7 thru Windows 10. Details and download available at:
http://bytepointer.com/articles/vs7.1_2003_on_win7_pdb_handle_leak_bug_unofficial_fix.htm
If you want to perform the patch manually, those details are also included.
NOTE: The SysInternals Handle tool workaround did not work for files on a network-share. The .PDB was not completely unlocked although the Handle tool claimed it was closed. My fix eliminates the problem once and for all and avoids any side effects.
Run this install. You need to run it from the setup directory, the setup.exe on the root of the cd will not work.
D:\setup\SetUp.exe /NO_BSLN_CHECK
Solution i found on the web which helped: For your visual studio, use application compatibility = windows vista SP2, and NOT WinXP SP3
I have a really dirty and pathetic workaround for the pdb problem.
Download and run Sysinternals-ProceXP, press CTRL-F enter the name of pdb(smt like ($ProjectName).pdb) that can't be created while linking. Double click when it is found.(if it can't be found run procexp with administrator priviliges)
Then you will see that the .pdb file is highlighted in the lower pane of the main screen. Right click it and select Close Handle. When you retry building your solution it wont raise an error.
I dont know if this solution can be scripted but it is at least better than restarting visual studio.
I've been using Visual studio 2003 on win7 since the very first RC edition was released :S
why do people have issues?
I have attempted to install VS2003 on Windows 7 64-bit using the Virtual Windows XP feature. I'm reasonably certain that this will be successful. The issue I ran into is that the installer wants IIS installed, and the XP installation provided by the Virtual XP doesn't have that enabled by default.
If you go to Add/Remove components, and try to add it, it will ask for the disc, which I didn't have on hand. Once I get my hands on the disc, I'm pretty sure that it will run fine.
If you haven't tried it for other apps, the Virtual XP feature is really neat...
I am experiencing the same issue; devenv.exe is leaving pdb files open after running the project. I have made a batch file to work around it, it closes all .pdb files open by devenv.exe:
handle.exe .pdb | awk "/devenv.exe/ { split($4, fd, \":\"); system(\"handle.exe -c \" fd[1] \" -y -p \" $3)}"
You will need to have handle.exe by sysinternals and awk by gnu in your path to make it work.
Use at your own risk. Closing handles can cause application or system instability.
In windows 7, there is the compatabiliy mode in the executable properties.
open:C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\
then right click on the devenv.exe and select properties. In the compatability tab, select the "Run in compatability mode" and select "Windows XP" in the dropdown.
Try that, I am not sure if it works, but it is worth a shot.
I am having no problems with Visual Studio 2003 on Windows 7 64-bit.
Navigate to VS2003 devenv.exe (probably C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe)
Right-click and select Properties
In the Compatibility tab, check "Run this program in compatibility mode for:" and select "Windows XP (Service Pack 3)"
Check "Run this program as administrator"
I got Visual Studio .NET 2003 Working just fine on my HP EliteBook Workstation 8760W with an I7 processor and 12GB of RAM running Windows 7 Professional 64 bit by doing some advanced steps.
They go as follows:
Install FrontPage 2002 Server Extensions for IIS 7.0.
Install Visual Studio .Net 2003. Just skip when the installer command you to configure Frontpage 2002 Server Extensions.
Install .Net Framework 1.1 Service Pack 1 (download here).
Go to Control Panel > Administrative Tools > Internet Information Services (IIS) Manager. Highlight your machine, then double-click on ISAPI and CGI Restrictions. Change setting for ASP .NET v1.1.4322 to Allowed.
Then it will always show an alert with the following message
This program has compatibility issues...
just ignore that. Also, don't put it in compatibility mode in the properties of the IDE.
I did managed to install VS2003 on Windows 7 32 bit. However I had to do some IIS tricks in order to be able to run my ASP.NET project. When you install VS2003 Web Development component can't be selected. Basically you have to drop your VS2003 ASP.NET v1.1 into C:\inetpub\wwwroot\project_name and make it working on it's own as a standalone web portal first. Here is the steps I did.
Install IIS on Windows 7
Copy your VS2003 project to C:\inetpub\wwwroot\project_name. Right click on your project_name and Convert to application.
Following was my custom issue that didn't work until I enabled Windows Authentication even if I had no related settings in my web.config. Select your project_name > Authentication > enable both Anonymous and Windows Authentications.
Enable ASP.NET 1.1 in ISAPI and CGI Restrictions and make sure ASP.NET is added under ISAPI filters
Once I'm able to fire up my ASP.NET project in a browser go ahead and open project from your project location in my case is C:\inetpub\wwwroot\MHSScoreOrg\MHSScoreOrg.sln. I was able to run my project only when it was fully integrated on IIS.
I'm sorry, your build environment requires you to have VC 2003, 2005, AND 2008 running concurrently? I would really bet that your efforts would be better spent simply consolidating your build environment to just one environment.
Have you considered upgrading your solutions to vs2005, using MSBEE to target .net 1.1?