Fix: “A numeric comparison was attempted” at VS build (Costura.Fody)

After upgrading from Visual Studio 2017 to Visual Studio 2019 I was able to update NuGet packages Fody and Costura.Fody of a solution that needed them (to package assembly DLLs inside console EXEcutables) and the solution was rebuilding fine.

However after I synced the solution via a Git repository on another machine and installed the newer Visual Studio there too, I rebuilt the solution in order to fetch/rebuild NuGet packages too and although everything seemed to rebuild fine, when I was using a plain build instead of a rebuild all I was getting at Errors dialog for each project that was using Costura.Fody:

Error

A numeric comparison was attempted on "$(MsBuildMajorVersion)" that evaluates to "" instead of a number, in condition "($(MsBuildMajorVersion) < 16)".  

To fix this I had to uninstall and reinstall Costura.Fody NuGet package (it wasn’t needed to uninstall/reinstall the Fody NuGet package itself) on the solution’s projects that were using it and then all was rebuilding/building fine again on that other machine.

Fix: “The Global element ‘xx’ has already been declared” warnings in config files after .NET framework upgrade in Visual Studio solution

Had just converted to target .NET framework 4.7.2 a Visual Studio solution full of 4.5 libraries, console apps and an MVC 5.0 (recently converted from 4.0) web app and all seemed to build fine, but then noticed that with web.config of the MVC web app open in the editor, it was showing lots of warnings of the form:

The Global element ‘xx‘ has already been declared in …

and marking them in the text with blue underscores under some whitespace

Seems others have had this issue too with configuration files (both ASP.net and Entity Framework ones) after changing target .NET framework:

https://stackoverflow.com/questions/11816916/fix-the-global-element-configuration-has-already-been-declared

Luckily the solution was hidden in that thread, just had to pick the best one (read on below)

– at https://stackoverflow.com/a/52274659/903783 one reads (see related screenshot there):

I noticed this issue with my VS2017.

Changing DotNetConfig.xsd to use "Automatic" solved the problem.

This doesn’t seem to work permanently (only worked once for a while for me)

– at https://stackoverflow.com/a/28114738/903783 is says:

With the symptoms as described in the question, and using Visual Studio 2013 (Update 4), I could see in the XML Schemas [sic] dialog that both DotNetConfig.xsd and DotNetConfig40.xsd were selected for use.

I’m using a .NET Framework 4.0 project.

The two XSD files conflict with each other, each defining the same elements, causing the warnings to be emitted.

These schema files are contained in the %programfiles(x86)%\Microsoft Visual Studio 12.0\xml\Schemas\ folder.

DotNetConfig.xsd is in the 1033 sub-folder and appears to be the newer, more complete version.

No matter what settings I selected in XML Schemas, I could not deselect, or remove DotNetConfig40 nor DotNetConfig. I tried "Remove", and changing the Use parameter from "Use this schema" to "Automatic" and then "Do not use this schema".

No matter what was selected, for either file, when I would return to the dialog, both would be selected for use. I also tried the trick of moving to another row before pressing "OK" to no avail.

Finally, I renamed the DotNetConfig40.xsd file to DotNetConfig40 DO NOT USE.xsd to prevent it from being loaded. This immediately solved the problem.

This does work (adapting the path for VS2017), but one isn’t sure (unless they check the file dates maybe) which file to keep, in my case it was 1033/DotNetConfig.xsd and DotNetConfig45.xsd, nor are they sure this won’t cause any side-effects in other solutions/projects.

– Finally, at https://stackoverflow.com/a/33823331/903783 it read:

I struggled with this for a while as well. Turns out, my version of the problem originated from the hidden {PROJECTNAME}.SUO file created by Visual Studio.

My guess is, VS will cache the XSD schema associations in this file. The warnings popped up after I changed the target framework, and they disappeared after I deleted the SUO file and restarted VS.

This fixed it permanently. Deletion of the .suo ended up with the DotNetConfig.xsd and removed the DotNetConfig45.xsd from the XML schemas list for the projects in the solution. In fact I deleted just a .suo file with no filename part, just a file extension, found by typing “.suo” at the search filter in the top-right of the solution’s folder window in Windows 10 File Explorer.

Suggestion: Visual Studio should offer to implement callbacks

I type-in new PropertyMetadata(OnCenterXPropertyChanged) but since I haven’t yet implemented On…, I get a suggestion by the IDE to implement it but it suggests to add field, property or read-only field, not to implement the callback for me with the given name. It can find the method signature needed from the delegate that PropertyMetadata (one of its overloaded versions) expects.

It came to me while I was trying to implement Silverlight’s CompositeTransform for WPF:

public static readonly DependencyProperty CenterXProperty = 
  DependencyProperty.Register("CenterX", typeof(double), 
    typeof(CompositeTransform), 
    new PropertyMetadata(OnCenterXPropertyChanged));

for the Compatibility library I maintain at http://github.com/zoomicon/Compatibility. I have used that library a lot in ClipFlair to maintain a common C# source and XAML between Silverlight and WPF projects (I do code sharing between projects via linked files).

Can vote for this suggestion at:

http://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10906626-offer-to-implement-callbacks

HowTo: Remove unused references and using clauses in Visual Studio

I recently posted a list of the VS2015 extensions I use on my main machine at: https://zoomicon.wordpress.com/2015/11/13/visual-studio-2015-extensions-i-use/

From that list of extensions I use the Productivity Power Tools one, it has a "Power Commands > Remove and Sort Usings" action that one can right click and run on the whole solution. Much easier than opening it for each

There is another nice extension called ResolveUR that is not available for VS2015, but only for VS2013 (think you can edit its .vsix and make it work for it too though, see the process for other similar extension explained at https://devio.wordpress.com/2014/12/03/remove-unused-references-with-visual-studio-2013/). I usually open up the solution in VS2013 too just to run that. Resharper also has such functionality as shown at:

https://www.jetbrains.com/resharper/help/Refactorings__Remove_Unused_References.html

Alternative is to use the Copy References extension and right click a reference under the References subtree of a project, then select "Copy Reference", then Remove the reference and rebuild that project. If rebuild fails, then right click at the References again and select Paste Reference. Then repeat till you remove all references that are not needed

In fact one should FIRST remove all unused using clauses and THEN remove unused references. That is because some files like App.xaml.cs, AssemblyInfo.cs may have using clauses that they don’t really use. So unless those using clauses are removed, the compiler thinks respective references to assemblies those namespaces were at are needed

Visual Studio 2015 Extensions I use

This is the complete list of Visual Studio 2015 Extensions I’m using currently: