This is my answer at:
to the question on why some extensions fail to install at RC (Release Candidate) versions of Visual Studio 2015, showing error “SignatureDescription could not be created for the signature algorithm supplied”.
Not sure if Microsoft fixed this on purpose or by accident, but this is very useful for people who don’t have the time (and courage) to uninstall the RC version and reinstall the final one and all extensions they were using.
Speaking of reinstalling everything by hand, it would be nice if you could export an XML document containing a list of installed Visual Studio extensions and then be able to reimport it to install them all at an other Visual Studio installation (should also be able to edit that XML document to remove some if you wish, or at export see a checkbox list to deselect ones you don’t want exported in the resulting list).
To keep it short, the answer is:
I used Custom installation option and selected everything. It upgraded Visual Studio 2015 Enterprise RC to Visual Studio 2015 Enterprise automatically and now those extensions that had started recently to not install, are installing fine. That way you’ll avoid the trouble of reinstalling everything.
Note that after installation finishes it shows a button to Launch Visual Studio, which will launch the Enterprise edition (or Professional in the case I guess one had Professional RC installed). However your Windows taskbar shortcuts for Visual Studio 2015 and Blend 2015 will be now broken and you have to fix them by right-clicking them and selecting Properties, then setting them to C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe and C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\blend.exe respectively, assuming you use an 64-bit OS – else remove the “ (x86)” part – and had installed Visual Studio on C: disk. You may wish to also add those links to the Start menu, under the respective folder (named Visual Studio 2015) if you also miss them from there.
Copying here those comments of mine at a discussion on the GraphX project:
looking at the folders/projects/libraries/namespaces naming, I think it would be more appropriate to add the platform at the end of the name, say GraphX.somePart.PCL, GraphX.somePart.UWA (=Universal Windows Application model [aka Win10]) etc. Not sure how easy it will be though for contributors to merge pending changes via GitHub if you do such drastic changes (I’m still struggling with Git myself, prefer Mercurial)
Speaking of moving the platform to the end of the name (e.g. GraphX.Controls.WPF, GraphX.Controls.SL5 etc.), to do it on the folder names (apart from doing at the source code for packages, target assemblies etc.), I think one has to use some Version Control command to "move" (Git should have something like that) the files to the new folder, else other contributors may have issue merging their changes.
Despite the trouble to do it, I think it is better for the long run. Also, all GraphX.SomePart.* subfolders could then be grouped in a GraphX.SomePart folder as subfolders where a Source or Common subfolder would also exists that has all the common code those platform-specific versions of GraphX.SomePart share (via linked files to ..\Common\SomeFile, ..\Common\SomeFolder\SomeFile and ..\Common\SomeOtherFolder\SomeFile etc.)
This is the scheme I’ve been using (and I’m very satisfied with) at http://clipflair.codeplex.com and other projects (e.g. at the AmnesiaOfWho game [http://facebook.com/AmnesiaOfWho] that has separate versions for SL5, WP7 and WP8 and WPF version on the works, plus WRT (WinRT) and UWA [Universal Windows App] too coming in the near future, with all code and most XAML shared via linked files and UserControl[s])
I meant I’d expect GraphX.Common folder with GraphX.Common.PCL in it and GraphX.Common.WP7 etc. versions for example also in that folder since PCL is usually set at WP8 level. This is just an example.
What I’m saying is that the platform name is the last part of the specialization chain, so logically GraphX comes first then say comes Controls then comes WPF, SL5, WP8 etc. in the folder name.
Also would have 3 parent folders Controls, Common and Logic. The last two would just contain the respective .PCL subfolder for now, but I can contribute subfolders for specific platforms too, esp for those the common PCL profile doesn’t cover. Source would be at Controls\Source, Common\Source, Logic\Source and respective platform specific projects (even the pcl projects) would use linked files
GraphX (contains GraphX.sln)
—-\GraphX.Controls.SL5 (contains GraphX.Controls.SL5.csproj)
—-\GraphX.Controls.WPF (contains GraphX.Controls.WPF.csproj)
—- … (more platform specific versions)
—- … (platform specific versions, esp. those not covered by the settings chosen at the PCL)
—- … (platform specific versions, esp. those not covered by the settings chosen at the PCL)
The same structure would also be used at examples to cover the potential of porting some of them to more platforms:
Of course common code at each folder is at the Source subfolder of that folder, shared using linked files (e.g. at \Examples\SomeExample\Source) and platform specific code is inside the respective projects (e.g. at \Examples\SomeExample\SomeExample.WPF)
Similarly the GraphX.sln would contain solution folders "Controls", "Common" and "Examples", though it could also contain separate solution (virtual) folders per platform that have each one of them "Controls", "Common" and "Examples" in them. That is the solution’s folder structure is organized per-platform in such a case. This is mostly useful if you want to focus on a specific platform each time when developing. However since the solution folders are virtual, one could even go as far as having two solutions, one with the same structure as the filesystem folders I suggest and one with a per-platform/target structure.
I follow the per-platform virtual solution folders style at ClipFlair.sln in http://clipflair.codeplex.com, while the real folders are structured as I describe above (where each module has its own physical subfolders for the various platforms). In fact some module subfolders there (say Client\ZUI\ColorChooser) contain their own extra solution file when I want to be able to focus just on a certain module. That solution just includes the respective ColorChooser.WPF, ColorChooser.SL5 etc. subprojects from respective subfolders). Such solutions also contain virtual WPF, Silverlight etc. subfolders that has as children apart from the respective platform-specific project (say ColorChooser.WPF) any other platform-specific projects needed (e.g. ….\Helpers\Utils\Utils.WPF\Utils.WPF.csproj etc.) by that module to compile.
Speaking of Xamarin, adding support for that too could follow the same pattern as described above (PCL where possible and platform-specific versions for .XamarinIOS, .XamarinAndroid etc. where needed)
Have again suggested this long before to Visual Studio team, but since Visual Studio 2013 has a “Send a Frown” feature, I’ve sent it again with some suggestions on how it could be implemented.
I need some clever replace in cases like that one shown in the screenshot below, where I have the implementation of a Sounds property and want to clone that and rename it to Music (this is useful when repeating a coding pattern, but more importantly can use this when refactoring code and need to rename something).
When doing replace on the selection, replacing "sounds" to "music", I want the word/target phrase to detect the casing of the source word/phrase and keep the same casing style, that is:
– IsSoundsOn should become IsMusicOn
– soundsOn should become musicOn
– PROPERTY_SOUNDS should become PROPERTY_MUSIC
As you can understand now I have to do 3 replacement operations, having selected the option "Case sensitive":
– Sounds to Music
– sounds to music
– SOUNDS to MUSIC
I’d rather have an option "Case adaptive" or something like that (marketing people might call this "Smart replace").
Implementation-wise, every time it detects the source text (case insensitive search), it would check if it is found in one of the following casings:
– first letter non-capital
– first letter capital
– all letters small
– all letters capitals
and when replacing with the target text it would apply the same casing state to it (affecting just the first letter of the target or all letters depending on which of the above casing states were detected for the source string at each position it was found in the source text)
Just sent this to the Visual Studio team via the “send a frown” button:
pressing CTRL+SPACE after "buttonDropDown." (see screenshot) seems to give me suggestions of members of buttonDropDown that aren’t a fit to the Rectangle object that I’m trying to assign to
I suppose you do so since I could eventually drill down into more properties of those objects
you could think of it as a tree though and from the current object’s (buttonDropDown) members give me as suggestions only those that satisfy condition X, where condition X would be defined recursively as "is a Rectangle or has members that satisfy X". Could maybe have some max depth in that case down to which you check and have an option at the end of the popup to show all members to pick from
another idea (easier to implement) is to show on top of the popup the members that are Rectangle and then the rest of the members separated visually, however I think the former suggestion is possible to implement and more powerful, plus could be combined with this later suggestion
Recently, to save myself sometime after having renamed some interfaces/classes in the ClipFlair project sourcecode, I right-clicked one of the class diagrams (.cd files) in it at Visual Studio’s “Solution Navigator” (this is an enhanced Solution Explorer addon) and using “Open With…” I opened up the diagrams with the XML editor to do a rename-all operation for the respective class names.
However, after saving the project I found out that from then on, that specific .cd file was opening up as XML file when double-clicked instead of opening up as a Class Diagram in the respective designer pane. Using Open With dialog would open it as a Class Diagram when asked to specifically, but using the checkbox to always open up as Class Diagram wouldn’t help fix the double-click problem for that specific .cd file (others would open up fine as class diagrams, not as XML files, when double-clicked).
I just managed to fix that issue by right clicking the file node in solution navigator’s tree and and excluding that file from the project (not deleting!), then saving the project, closing the solution containg the project and adding the file (via “Add existing file”) again after having reopened the solution. I could also possibly have right clicked selected “Unload project” after saving it and then select to reload it again, think that would have worked too.
Using VisualHG addon for Visual Studio I commited the changes to the Mercurial repository used by ClipFlair on Codeplex, which showed me that the file difference that did the fix was the following in the .csproj project file:
<None Include="Diagrams\Windows.cd" />
- <None Include="Diagrams\Windows.Views.Interfaces.cd">
+ <None Include="Diagrams\Windows.Views.Interfaces.cd" />
<None Include="Diagrams\Windows.Views.ViewModels.cd" />
That is instead of that marked-as-bold entry above (marked by the diff tool with – prefix), the line marked with + prefix should be used instead. This is obviously some bug in Visual Studio 2010, it’s nice to know though that you can easily take the project offline and edit the .csproj to fix it (or remove the .cd file, save the project, reload it and add the file again).