Assuming I want the newest flavour of visualstudio that is able to open C# projects, and if there are multiple (pro/express), I'd like to open pro.
edit: I want my own program to open visual studio on the computer of my program's user.
Is this the sort of thing that would be changing with great frequency? If not, I'd just do a search on your PC for "devenv.exe" (the VS executable) and then associate *.cs, *.csproj, *.sln, etc. files to open automatically with the "newest flavor" found that you want to use.
Edit: You could try having your program check the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio registry entry and retrieve the latest version from there, then have your program open the file using the Visual Studio executable at the appropriate location.
There isn't one API available that will simply open the latest version of Visual Studio. This is especially true when you start to consider the impact of expression versions of Visual Studio (and the ones which can open C# projects).
I think you're best bet is to simply create a list of Visual Studio versions that you care about in priority order. Then enumerate them in your process checking for the first one that is available and launching that process.
The most reliable way to find the installed location of Visual Studio is to examine the InstallDir key inside of
32 Bit: HKLM:\Software\Microsoft\VisualStudio{VersionNumber}
64 Bit: HKLM:\Softawre\Wow6432Node\Microsoft\VisualStudio{VersionNumber}
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 rely on the Find in Files dialog in Visual Studio a great deal. (Sometimes Intellisense/Resharper just don't cut it.) Since upgrading to 2015, I've noticed that the dialog doesn't remember my custom "Look in" paths or "Look at these file types" lists between sessions.
If I close my solution and VS instance, then reopen, I have to enter my custom path and file types again. Huge waste of time. Has anyone run else run into this? Any workaround? 2013 used to remember this stuff.
Microsoft Visual Studio Professional 2015
Version 14.0.23107.0 D14REL
Microsoft .NET Framework
Version 4.6.00081
Installed Version: Professional
I've never had any problems with it not remembering my settings, but I imagine that you could run a custom registry modifier to add the appropriate keys, you could make sure your settings are always pristine. The custom search information is stored in HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0\Find.
The file types are stored in a string key called Filter with whatever you would normally input into the custom file type category in the VS search window. For example searching for only .cs and .txt files you would put *.cs;*.txt.
The folders are located in a string key called Query with values such as C:\Folder1;C:\Folder2. However, it's behavior seems a little weird. You have change the value of Query and a Query+integer value (i.e. Query0) to the same value to have it appear in Visual Studio.
If you just run a script to modify the above values to the files types/folder locations you want, that should work.
I ran into this today. After much searching I found a post on the visual studio forums somehow. This pointed me towards ReSharper. This directed me towards a workaround.
Start visual studio in safe mode with the command line argument /SafeMode
Create the folder sets you want for searching
Restart visual studio not in safemode
Once I had restarted all my created custom searches remained, and the registry values were created. This might not work in the specific case, but this worked for me.
You can set these values programmatically inside Visual Studio for the Find and Replace dialog (for example with Visual Commander):
DTE.Find.FilesOfType = "*.txt";
DTE.Find.SearchPath = #"c:\temp";
If you have an earlier version of VS, export the environment settings, copy the NumberOfScopes and NamedScopes* settings from the Environment_UnifiedFind section to the same section in your VS2015 settings file and then re-import settings.
Once I did this, it allowed VS2015 to start saving folder specifications for future settings exports.
Or you could try replacing this in your VS2015 export:
<PropertyValue name="NumberOfScopes">0</PropertyValue>
With this:
<PropertyValue name="NumberOfScopes">1</PropertyValue>
<PropertyValue name="NamedScopes>0">FOLDER_SPEC_NAME>SEMICOLON_SEPARATED_LIST_OF_FOLDERS>{4A812F3C-7B1A-4987-9769-461F20EB25CB}</PropertyValue>
(Don't forget to re-import after you make the change)
I'll keep it short and simple. I had a OCZ Vertex 100Gb SSD that I had my operating system and programming tools aka VS2010. Anyway the drive failed and Windows went kaput, however I am able to recover certain folders including all those related to VS2010.
My question is where will the old macros be stored and how if possible do I copy them to my new VS2010 install on my new O/S ? I don't want to have to re-program all my macros again.
By default Visual Studio 2010 stores user recorded macros in "%userprofile%\Documents\Visual Studio 2010\Projects\VSMacros80", you can just copy that folder to the new drive to get them on the new install (you may have to load them manually).
Years ago, using VS2005, I had a setup where I could right-click on the desktop/folder, select New, select Visual Studio 2005 solution and it would create a solution for me right there. I can't remember how I did this.
Does something like this exist for VS2008 or VS2010? It would be really handy.
EDIT: Figured it out based on the links in the answers (and also found an old email to myself).
1. Create a registry file (.reg) with the following content, then execute it:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.sln\ShellNew]
"FileName"="Visual Studio Solution.sln"
2. Create a new file called Visual Studio Solution.sln in C:\Windows\ShellNew folder with the following content:
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Global
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal
3. Reboot Windows and you'll have yourself a context menu.
I used to use what I think you are looking for. It was done with a little registry update (.reg) file whose contents start like this
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.sln\ShellNew]
"Data"=hex:EF,BB,BF,D,A,4D,
of which this is just a snippet, and it was for an earlier version of VS. But this might be enough to jog your memory, or give you something to google for. See here for more
http://flux88.com/2009/03/right-click-new-visual-studio-solution/
edit..
also see http://visualstudiohacks.com/registry-hacks/create-solutions-without-folders/
I believe the Team Foundation Server edition of Visual Studio does that, either stand alone or with the Team Foundation Server Power Tools, which the Power Tools site says it has Windows Shell Extensions.
Also Codeplex hosts MSBuildShellExtension which is a little off topic for what your looking for, but its nice because it lets you build your project from any directory on your hard drive, without ever having to launch Visual Studio.
1) In Visual Studio 2010, use the "Blank Solution" project to create a solution.
2) Copy that SLN file into "%SystemRoot%\ShellNew".
3) In RegEdit, go to HKEY_CLASSES_ROOT.sln
4) If a key (folder) for "ShellNew" does not yet exist under .sln, create it.
5) Create a string value under ".sln" with a name of "Filename" and the filename of the SLN file for its data.
Done. No restart necessary.
REF: http://support.microsoft.com/kb/140333
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.