Fix: VSIX installer error – SignatureDescription could not be created

This is my answer at:

http://stackoverflow.com/questions/31552082/vsix-installer-signaturedescription-could-not-be-created-for-the-signature-algo/

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:

Try installing http://go.microsoft.com/fwlink/?LinkID=619615 (found from http://blogs.msdn.com/b/somasegar/archive/2015/07/29/building-apps-for-windows-10-with-visual-studio-2015.aspx)

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.

Class diagrams for Hotspotizer Kinect-based application source code

Following are class diagrams for Hotspotizer’s C# code, as is currently at 4 Aug 2015 at its refactored version I maintain in my fork at GitHub (http://github.com/birbilis/hotspotizer). The respective diagram (.cd) files for Visual Studio are available in the code repository at the various subfolders:

Structuring (physical) source and (virtual) solution folders for portability

Copying here those comments of mine at a discussion on the GraphX project:

https://github.com/panthernet/GraphX/issues/21

describing the source code (physical) folder structure and the Visual Studio solution (virtual) folder structure I’ve been using at ClipFlair and other multi-platform projects.

——

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

aka

GraphX (contains GraphX.sln)

–\Controls
—-\Source
—-\GraphX.Controls.WP7
—-\GraphX.Controls.WP8
—-\GraphX.Controls.SL5 (contains GraphX.Controls.SL5.csproj)
—-\GraphX.Controls.WPF (contains GraphX.Controls.WPF.csproj)
—-\GraphX.Controls.WIN8
—-\GraphX.Controls.UWA
—- … (more platform specific versions)

–\Common
—-\Source
—-\GraphX.Common.PCL
—- … (platform specific versions, esp. those not covered by the settings chosen at the PCL)

–\Logic
—-\Source
—-\GraphX.Logic.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:

–\Examples
—-\SomeExample
——\Source
——\SomeExample.WPF
——\SomeExample.SL5
—-\SomeOtherExample
——\Source
——\SomeOtherExample.WIN8
——\SomeOtherExample.UWA
etc.

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)

Suggestion: Case adaptive text replacement in Visual Studio editor

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)

Suggestion: Making Intellisense in Visual Studio more Intelligent

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

 

Fix: Visual Studio opens class diagram in XML editor with double click

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:

   <ItemGroup>
     <None Include="Diagrams\Windows.cd" />
-    <None Include="Diagrams\Windows.Views.Interfaces.cd">
-      <SubType>Designer</SubType>
-    </None>
+    <None Include="Diagrams\Windows.Views.Interfaces.cd" />
     <None Include="Diagrams\Windows.Views.ViewModels.cd" />
   </ItemGroup>

 

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).

HowTo: Make Project Linker extension’s VSIX install at Visual Studio 2012

Project Linker is a Visual Studio Extension that “helps to automatically create and maintain links from a source project to a target project to share code that is common to Silverlight and WPF”.

In ClipFlair, where I have shared code between a Silverlight and a WPF project (I guess same would be for XNA projects for Xbox360 and for PC), a practice I use is to put shared files in a “Source” project and add them to both projects as links (using “Open as link” action available from Add file dialog if you press the dropdown arrow next to the “Open” button).

An alternative is to put such files in say the WPF project and use the Project Linker tool from Microsoft Patterns & Practices group to link to those files from the Silverlight project easily.

However, that tool seems to be only available for Visual Studio 2010, not for the newer 2012 version. Luckily, some users have posted a workarround at the discussion there (Reviews and Q&A tabs):

1. Download the .vsix
2. Extract contents with 7-Zip (since .vsix is a .zip file which you can see by renaming to .zip or .vsix.zip)
3. Modify file with extension .vsixmanifest to add <visualstudio version="11.0"> to the <supportedproducts> node
4. Change MaxVersion to <supportedframeworkruntimeedition minversion="3.5" maxversion="4.5" /> (this may not be necessary)
5. Zip up contents again
6. Rename extension back to .vsix
7. Install extension

According to comments there, this works but not for all project types. It works if one links the Silverlight project to the WPF one, but not the other way around. It throws a NullReferenceException somewhere in the extension.

How to crash Visual Studio 2010 via (Silverlight) XAML recursion bug

Following up on a note about Visual Studio 2010 crashing at my previous post, this is the XAML that crashes VS2010 when opened up in a Silverlight project:

<UserControl x:Class="SilverlightApplication1.MainPage"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation&quot;
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml&quot;
  xmlns:d="http://schemas.microsoft.com/expression/blend/2008&quot;
  xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006&quot;
  mc:Ignorable="d"
  d:DesignHeight="300" d:DesignWidth="400">

  <UserControl.Resources>
    <ResourceDictionary>
       <Style x:Key="MyStyle" TargetType="StackPanel">
         <Setter Property="Margin" Value="0,5,0,5" />
       </Style>
    </ResourceDictionary>
  </UserControl.Resources>

  <Grid x:Name="LayoutRoot" Background="White">

    <Grid.Resources>
      <Style TargetType="StackPanel">
         <Setter Property="Style" Value="{StaticResource MyStyle}" /> <!– THIS LINE CRASHES VISUAL STUDIO (EVEN WHEN YOU TRY TO TYPE IT IN) –>
      </Style>
     </Grid.Resources>

   <StackPanel/>

  </Grid>

</UserControl>

This crashes VS2010 upon loading, because it tries to show the XAML page in the designer. I created that XAML in Notepad++ since when I was trying to type the problematic line (marked in the XAML above) it crashed VS2010 immediately before I managed to save.

BTW, you should use the XAML syntax I suggested at my previous post that uses Style inheritance instead (although it would be nice if you could do for any node <X CloneSource=…/> for any XAML node to copy its attributes and values from a same-typed node instance in some resource etc. instead of relying on the node supporting some mechanism like Style does with BasedOn [that is Style Inheritance]).

<Grid.Resources>
   <Style TargetType="StackPanel" BasedOn="{StaticResource MyStyle}" />
</Grid.Resources>

 

Speaking of crashes, VS2010 should be more clever and if it sees a certain file caused a crash (assuming it has info on file being loaded upon or just before crash), the next time of opening the solution it should warn the user against opening that file (to avoid a new crash that stops one from loading the solution).

 

Note that I tried to open up the XAML file standalone in Visual Studio and it says:

Style object is not allowed to affect the Style property of the object to which it applies.
   at System.Windows.Setter.Seal()
   at System.Windows.SetterBaseCollection.Seal()
   at System.Windows.Style.Seal()
   at System.Windows.StyleHelper.UpdateStyleCache(FrameworkElement fe, FrameworkContentElement fce, Style oldStyle, Style newStyle, Style& styleCache)
   at System.Windows.FrameworkElement.OnStyleChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
   at System.Windows.DependencyObject.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
   at System.Windows.FrameworkElement.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
   at System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args)
   at System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType)
   at System.Windows.DependencyObject.InvalidateProperty(DependencyProperty dp)
   at System.Windows.FrameworkElement.UpdateStyleProperty()
   at System.Windows.TreeWalkHelper.InvalidateOnTreeChange(FrameworkElement fe, FrameworkContentElement fce, DependencyObject parent, Boolean isAddOperation)
   at System.Windows.FrameworkElement.ChangeLogicalParent(DependencyObject newParent)
   at System.Windows.FrameworkElement.AddLogicalChild(Object child)
   at System.Windows.Controls.UIElementCollection.AddInternal(UIElement element)
   at System.Windows.Controls.UIElementCollection.Add(UIElement element)
   at System.Windows.Controls.UIElementCollection.System.Collections.IList.Add(Object value)
   at Microsoft.Expression.DesignModel.InstanceBuilders.ClrObjectInstanceBuilder.InstantiateChildren(IInstanceBuilderContext context, ViewNode viewNode, DocumentCompositeNode compositeNode, Boolean isNewInstance)

Probably it loads it into an implicit WPF project. So is this some issue with Silverlight 5 XAML loading only? And if so isn’t this a potential exploit against Silverlight apps/plugin (if they allow XAML to be passed to them that is)?

It would be interesting to fix the test solution manually to not try to load the XAML file at startup, then build it and run it to see if it crashes the Silverlight plugin, the web browser, or whatever other side-effects it causes that might be exploitable.

This issue has been submitted to Microsoft at https://connect.microsoft.com/VisualStudio/feedback/details/753211/xaml-editor-window-fails-with-catastrophic-failure-when-a-style-tries-to-set-style-property. I have attached a test Silverlight project there (should be available for download soon [takes a while] from issue details)

Fix: The tag XXX does not exist in XML namespace ‘clr-namespace:YYY’

I just had some big trouble troubleshooting the Visual Studio / XAML compiler error message:

The tag XXX does not exist in XML namespace ‘clr-namespace:YYY’

It turned out this occurred because I had a Silverlight library with Assembly name X and default namespace X (at properties pane), but was using it from a demo project with Assembly name X (again!) and default namespace X.

If I removed the ";assembly=X" part from the XAML it worked fine, that is:

xmlns:my="clr-namespace:X"

Fixing the demo project to use Assembly name X.Demo and default namespace X.Demo (at its Properties pane), instead of having the same assembly name, now allows me to also use

xmlns:my="clr-namespace:X;assembly=X"

without problem.

Seems that when you have multiple assemblies with the same name in a project (wonder how the filesystem supports that), all of them are loaded fine and if they have classes with namespace X in them, the namespace gets classes from both assemblies (that’s why the xmlns without assembly=… works). When you specify assembly name in the XAML of a given project, it assumes you mean its own assembly, not any other referenced one with the same name.

BTW, at add references dialog I was using Projects option (to reference the output of other project in solution) and the project I was referencing was named X.Silverlight (can be named anything), I had not added reference the X assembly .dll file directly. Maybe that played its part too in the issue.

There may be other cases too that can cause this error to fire up, see:

http://social.msdn.microsoft.com/Forums/en/wpf/thread/56f933c8-a093-4c47-8e1a-cde4bb1864e9

Fix: Visual Studio 2010 XAML Designer output for WP7 light theme

The other day I submitted my 1st Windows Phone 7 application via http://create.msdn.com

Having registered for free as a student developer (being a PhD student on Robotics) via http://dreamspark.com I could only try my 1st app on WP7 emulator – when it gets accepted I will be able to have my WP7 phone unlocked to try apps there too.

So I was disappointed a bit to get back a certification failure. One of the two reasons stated was that I wasn’t following one key WP7 (design) guideline/requirement: to have the app UI work fine in both dark and light theme of WP7. I was using the default design colors and brushes, not having set any colors explicitly and since the emulator was starting in dark theme by default, this issue slipped my attention (wouldn’t it be nice if the Visual Studio XAML designer allowed you to switch between dark and light theme?).

The (nicely organized) feedback PDF from the Certification step of the WP7 app marketplace submission process was saying:

At first I couldn’t find the settings at the WP7 emulator since the image button pointing to the right to go to the settings page wasn’t visible (probably because of my video card not supporting the latest shader model and running the emulator ignoring the warnings shown that only Silverlight – not XNA – content will show up and probably not always fine – obviously meaning functionality that is implemented using GPU hardware acceleration in the emulator).

Dragging to the left on the 1st screen of the emulator (that just shows IE) takes you to the apps page where you also see Settings and your deployed app (apart from IE). You can hold down mouse on Settings there and select to Pin it to 1st page for easier access. At settings you can change the Theme Background to “light” instead of the default “dark” and try your app again.

In my app’s case indeed you couldn’t see a thing. The article that gave me a hint to what might be happening was:

http://timdams.wordpress.com/2011/06/21/creating-a-wp7-app-supporting-dark-and-light-themes/

and especially the phrase:

when the light theme is active, what WP7 basically does is switch the Foreground and the Background property of all controls, as long as they’re not defined explicitly.

The moment however, you define a specific color for a control, WP7 won’t help you with switching colors anymore

So I took a look again at the XAML code the Visual Studio 2010 designer for WP7 Silverlight app had generating. I noticed the XAML had Background=”Black” at various controls (like Grid, Pivot etc.).

Comparing with a newly created project I noticed it just had Background=”Transparent” for Grid. I later on remembered that at some point it was showing Pivot pages one over the other (due to wrong nesting in the XAML) which had set me changing the Background to “Black” at various controls trying to work around the overlap issue.

Doing a replace all for { Background=”Black”} (with a space prefix) and replacing with {} (that is nothing) is the first step needed for the fix.

The 2nd step is to add to the XAML header the missing Background="{StaticResource PhoneBackgroundBrush}" attribute value assignment shown below in bold that seems to be missing (to use the phone’s background brush by default).

In fact most probably the 2nd issue is with the Silverlight WP7 Pivot application template (probably the same goes for the Panorama template) and not the XAML designer itself which may be WP7 agnostic altogether.

<phone:PhoneApplicationPage
    x:Class="MYPHONEAPPCLASSNAME.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
    xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
    xmlns:controls="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="768"
    FontFamily="{StaticResource PhoneFontFamilyNormal}"
    FontSize="{StaticResource PhoneFontSizeNormal}"
    Foreground="{StaticResource PhoneForegroundBrush}"
    Background="{StaticResource PhoneBackgroundBrush}"
    SupportedOrientations="PortraitOrLandscape"
    Orientation="Portrait"
    shell:SystemTray.IsVisible="True"
    Title="MYPHONEAPPTITLE"
    IsHitTestVisible="True">

A useful link regarding WP7 brushes is “Theme Resources for Windows Phone”:
http://msdn.microsoft.com/en-us/library/ff769552(v=vs.92).aspx

These suggestions have been submitted to Microsoft Connect and can be voted for at: https://connect.microsoft.com/VisualStudio/feedback/details/703467/vs2010-silverlight-xaml-designer-with-wp7-silverlight-app-templates-fail-at-wp7-light-theme