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.
Related
I have installed the Visual Studio 2015 and created Win32 project with some code. I compiled it successfully, but I can't launch exe file, because I don't have some ucrtbased.dll...So how can I solve it?
Edit:
The English equivalent message is:
"The program can't start because ucrtbased.dll is missing from your computer. Try reinstalling the program to fix this problem. "
This problem is from VS 2015 silently failing to copy ucrtbased.dll (debug) and ucrtbase.dll (release) into the appropriate system folders during the installation of Visual Studio. (Or you did not select "Common Tools for Visual C++ 2015" during installation.) This is why reinstalling may help. However, reinstalling is an extreme measure... this can be fixed without a complete reinstall.
First, if you don't really care about the underlying problem and just want to get this one project working quickly, then here is a fast solution: just copy ucrtbased.dll from C:\Program Files (x86)\Windows Kits\10\bin\x86\ucrt\ucrtbased.dll (for 32bit debug) into your application's \debug directory alongside the executable. Then it WILL be found and the error will go away. But, this will only work for this one project.
A more permanent solution is to get ucrtbased.dll and ucrtbase.dll into the correct system folders. Now we could start copying these files into \Windows\System32 and \SysWOW64, and it might fix the problem. However, this isn't the best solution. There was a reason this failed in the first place, and forcing the use of specific .dll's this way could cause major problems.
The best solution is to open up the control panel --> Programs and Features --> Microsoft Visual Studio 2015 --> Modify. Then uncheck "Visual C++ --> Common Tools for Visual C++ 2015". Click Next, then and click Update, and after a few minutes, Common Tools should be uninstalled. Then repeat, but this time install the Common Tools. Make sure anti-virus is disabled, no other tasks are open, etc. and it should work. This is the best way to ensure that these files are copied exactly where they should be.
Error Codes: Note that if the installer returns a cryptic error number such as -2147023293, you can convert this to hex using any of the free online decimal-to-hex converters. For this error it is 0xFFFFFFFF80070643 which, dropping the FF's and googling for "0x80070643", means `0x80070643 - Installation cache or ISO is corrupted'.
Why is ucrtbased.dll even needed?: Any DLL named "crt" is a "C-Run-Time" module or library. Microsoft explains them best. There are many variants of CRT today. They contain essential helper-code used by all Microsoft compiled executables, to "shim" or help your executable operate on the ever-growing number of OS versions and hardware. If the MSVC compiler is used, the relevant CRT DLL is linked automatically at compile-time. (If the DLL cannot be found at compile-time, then a linking error is generated.)
One way to not require the DLL, is to "statically-link" it to your project. This means that you essentially take the contents of ucrtbased.dll, and include it in your executable. Your file size will grow by approximately the size of ucrtbased.dll.
Incidentally, if you've ever run a MSVC program (usually from another individual, one of your old compiled programs from a previous OS version, or yours from a different machine) and it does not start, giving an error message of needing "Microsoft Visual C++ 20xx Redistributable" or "run-time" - then it means it can't find the needed *crt*.dll file. Installing that particular redistributable package (if known) will install the DLL, and allow the program to run... or at least get past that error and alert you of another missing DLL.
If you find yourself in this "DLL Hell" predicament, google "dependency walker" for an advanced tool to show which DLLs are still missing. This usually doesn't happen with professional software, simply because their (large, bundled) installers check for any missing dependent libraries (including CRT) and installs them first.
The problem was solved by reinstalling Visual Studio 2015.
rdtsc solution did not work for me.
Firstly, I use Visual Studio 2015 Express, for which installer "modify" query does not propose any "Common Tools for Visual C++ 2015" option you could uncheck.
Secondly, even after 2 uninstall/reinstall (many hours waiting for them to complete...), the problem still remains.
I finally fixed the issue by reinstalling the whole Windows SDK from a standalone installer (independently from Visual C++ 2015 install):
https://developer.microsoft.com/fr-fr/windows/downloads/windows-8-1-sdk
or
https://developer.microsoft.com/fr-fr/windows/downloads/windows-10-sdk
This fixed the issue for me.
An easy way to fix this issue is to do the following (click on images to zoom):
Make sure to close Visual Studio, then go to your Windows Start -> Control Panel -> Programs and Features. Now do this:
A Visual Studio window will open up. Here go on doing this:
Select the checkbox for Common Tools for Visual C++ 2015 and install the update.
The update may takes some time (~5-10 minutes). After Visual Studio was successfully updated, reopen your project and hit Ctrl + F5. Your project should now compile and run without any problems.
I would like to suggest additional solution to fix this issue. So, I recommend to reinstall/install the latest Windows SDK. In my case it has helped me to fix the issue when using Qt with MSVC compiler to debug a program.
I am not sure it will help but you can try this.This worked for me
Start -> Visual Studio Installer -> Repair
after this enable the Microsoft Symbols Server under
TOOLS->Options->Debugging->Symbols
This will automatically set all the issues.
You can refer this link as well
https://social.msdn.microsoft.com/Forums/vstudio/en-US/6aa917e5-a51c-4399-9712-4b9c5d65fabf/ucrtbasedpdb-not-loaded-using-visual-studio?forum=visualstudiogeneral
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'd like to use Qt inside the visual studio IDE, however whenever I create a new project and select the Qt template an error pops up:
Cannot find 'file:///D:/programs_on_d//Nokia/Qt4VSAddin/wizards/HTML/1033/default.html'. Make sure the path or Internet address is correct.
Yet when I browse to D:\progams_on_d\Nokia\Qt4VSAddin\wizards\Qt4GuiProject\html\1033, I do see the default.htm just there..
What am I doing wrong and how can I fix this?
Well seems to be depending on the phase of the moon - the problem just disappeared some time later. (Without any update occuring)
Cheers,
I have Microsoft VS 2005 installed (full version). And when I'm trying to build or debug my solution (with 10 projects) a windows installer window opens and says:
The feature you are trying to use is on cd-rom or other removable....
So I then put my VS2005 CD and VS does his thing and than my build and debug processes are working. But when I shut down VS and open it again and when I want again to build my solution it asks me the same thing.
I deleted VS2005 and installed it again (again full version) and it asks me the same thing. I am really crazy right now.. why VS just don't do "update" or something, I don't want to insert CD every time I start VS.
tnx
When Visual Studio was installed on your system, you might have chosen a typical installation or a custom installation that did not include everything available to it. This is appropriate in some cases (low disk space, you know only a certain subset is all that is aver or should ever be used).
Try reinstalling, and make sure its a complete install. And don't have it delete unused pieces.
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).