Visual Studio 2015 was apparently once going to be named Visual Studio 2014, based on some of the shortcuts installed with the recently released preview:
Continuing the Microsoft tradition of skipping version 13, the internal version number is 14 (Visual Studio 2013 being version 12).
Click here to see this bug on Connect.
Visual Studio 2013 configures Start Menu shortcuts differently to earlier versions. Specifically, it adds a shortcut to ‘Visual Studio Tools’ (%PROGRAMFILES(X86)%\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts), where Visual Studio 2012 added a directory called ‘Visual Studio Tools’ and added copies of the shortcuts. This is all a bit confusing, but the end result is that searching in the Start Menu/Screen won’t bring up results for useful things like the Developer Command Prompt or Spy++.
This annoyed me sufficiently that I wrote a PowerShell script (run it as administrator) to restore the shortcut directory:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
$shortcutpath = "$env:ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2013\Visual Studio Tools.lnk" $newshortcutdir = "$env:ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2013\Visual Studio Tools" If (Test-Path $shortcutpath) { $shell = New-Object -COM WScript.Shell $toolsdir = $shell.CreateShortcut($shortcutpath).TargetPath # create directory if necessary If (-Not(Test-Path $newshortcutdir)) { mkdir $newshortcutdir } # copy shortcut files copy "$toolsdir\*.lnk" $newshortcutdir # hide old shortcut $shortcut = Get-Item $shortcutpath -Force $shortcut.Attributes = $shortcut.Attributes -bor [System.IO.FileAttributes]::Hidden } else { "Shortcut not found." } |
The Visual Studio Shortcuts directory doesn’t contain shortcuts to Spy++ (and a number of other programs). Here’s another script to restore shortcuts to Spy++:
|
1 2 3 4 5 6 7 8 9 |
$shortcutdir = "$env:ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2013\Visual Studio Tools" $toolsdir = "${env:ProgramFiles(x86)}\Microsoft Visual Studio 12.0\Common7\Tools" $shell = New-Object -COM WScript.Shell $spyshortcut = $shell.CreateShortcut("$shortcutdir\Spy++.lnk") $spyshortcut.TargetPath = "$toolsdirspyxx.exe" $spyshortcut.Save(); $spyshortcut = $shell.CreateShortcut("$shortcutdir\Spy++ (64-bit).lnk") $spyshortcut.TargetPath = "$toolsdirspyxx_amd64.exe" $spyshortcut.Save(); |
Update (2012-09-06): After some trial and error, it seems the Canon Hack Development Kit (CHDK) component is causing the issue. If you’re experiencing the same problem, try removing this component.
Update (2012-09-05): The FastPictureViewer support team was unable to reproduce the issue, but suggested it might have something to do with the JPEG Auto-Rotate feature. I was able to resolve the issue by installing only the following components of the codec pack: Photoshop PSD, Lightroom Previews, Adobe DNG, Canon CR2, CRW, PDF Thumbnails and Control Panel. This suggests one of the other components was causing the conflict on my machines.
I use the FastPictureViewer Codec Pack for viewing DNG images in Windows Explorer, amongst other things. Unfortunately, however, installing version 3.3.0.69 of the codec pack in Windows 8 (64-bit) caused my installations of Visual Studio 2010, Visual Studio 2012, Blend 4 and Blend for Visual Studio 2012 to stop working to various extents. Both versions of Blend crash silently. The start pages in both versions of Visual Studio fail to load, with VS2010 displaying a ‘Content Load Error’ relating to ‘System.Windows.Baml2006.TypeConverterMarkupExtension’ throwing an exception. The error message displayed where the Visual Studio 2012 Solution Explorer belongs was more useful: ‘System.Runtime.InteropServices.COMException: The codec is in the wrong state. (Exception from HRESULT: 0x88982F04)’.
Uninstalling the codec pack caused everything to start working again. I’ll update this post if/when a future release resolves the incompatibility.
