Tag: win

Reactive Framework conflict (SOLVED)

The type ‘System.IObservable exists in both ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll’ and ‘c:\Program Files (x86)\Microsoft Reactive Extensions\Redist\DesktopV2\System.Observable.dll’ (SOLVED)

During an upgrade of a C# WPF application that was using Reactive Extensions, I ran into this compile error:

The type ‘System.IObservable exists in both ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll’ and ‘c:\Program Files (x86)\Microsoft Reactive Extensions\Redist\DesktopV2\System.Observable.dll’

This is roughly the same kind of Defined in Multiple Assemblies problem as I faced before. (Solution provided.)

In this case, the System.Observable.dll was pinned to the 3.5 release of the Reactive Extensions.

The solution was to:

  1. Download the .NET 4.0 version of Reactive Extensions (Rx_Net4.msi).
  2. Install it.
  3. Remove System.Observable from the project.
  4. Re-add the System.Observable to the project, being super careful to select the latest version

Defined in Multiple Assemblies

The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias … mscorlib.dll and System.Core.dll. SOLVED!

Today I migrated a C#/WPF project in Visual Studio 2010 from .NET 3.5 SP1 to .NET 4.0. Immediately the compile failed issuing this set of errors:

  • The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias; using definition from ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll’
  • The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias; using definition from ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll’

To resolve this error involved understanding a little bit more about C#, .NET, and the Common Language Runtime (CLR).

According to C# 4.0 In A Nutshell from O’Reilly Press, on page 181 it says:

Some of the .NET types are used directly by the CLR and are essential for the managed hosting environment. These types reside in an assembly called mscorlib.dll and include C#’s built in types, ….

At a level above this are additional types that “flesh out” the CLR-functionality, …. These reside in System.dll, System.Xml.dll, and System.Core.dll, and together with mscorlib the provide a rich programming environment….

So mscorlib and System.Core are both needed. This begs the question, why is Func declared in both and thus causing a conflict? Or is it?

Further on in C# 4.0 In A Nutshell from O’Reilly Press, on page 183 in a general note it says:

A notable exception is the following types, which Framework 4.0 have moved from System.Core to mscorlib.dll:

  • The Action and Func delegates
  • …

This suggests a case exists where mscorlib is from our current .NET (the later one has Func), and System.Core is coming from the old one (which is where Func lives for that version).

How is this possible? It’s our projects fault.

This question on StackOverflow provides some insight; check out Simon‘s answer.

  1. Right-click the project and select Unload Project
  2. Right-click the project again and select Edit Project
  3. Scroll down in the XML to find the ItemGroup element; it’ll have Reference elements insider of it.
  4. Locate the Reference element that has Include=”System.Core” as an attribute.
  5. If it has other qualifiers, remove them. If it has a TargetFrameworkVersion subelement remove it.
  6. Save the XML.
  7. Right-click the project and reload it; try a build now.

In my case, I had an entry that looked like this:

<ItemGroup>
  <Reference Include=”System.Core”>
    <TargetFrameworkVersion>3.5</TargetFrameworkVersion>
  </Reference>
</ItemGroup>

Removing the TargetFrameworkVersion, shown in red above, un-pinned the dll from the older .NET framework and things worked just fine.

WPF Responsiveness Problem

Ran into an interesting problem where a WPF application was acting really, really, really slow. So slow that moving the application window was jumpy. Selecting items in a grid would take several seconds. Scrolling a list box of simple items would grind the CPUs for a while. And even typing in a regular text box was so delayed that I could type a word, sit back, and every few seconds a character would appear.

The problem turned out to be with the input stack at the operating system. Seems that the Pen / Tablet Driver was bringing the system to its knees, but only affecting WPF applications.

Disabling the driver and restarting the WPF application instantly showed colossal speed improvements for response time; the application responded near instantly. Re-enabling the driver while the application was running reverted the system to the broken state, although turning the driver back off did not bring the WPF application out of it’s slow like crawl. Restarting the WPF application resolved the problem, but the driver had to be disabled.

(Test conducted with WPF 3.5 SP 1 and Windows 7.)

Clever Bulk Rename Trick in Windows

Stumbled into a clever way to rename a bunch of files to have the same prefix and a sequential numbered suffix… from the Windows GUI no less.

Ever want to rename a bunch of files to the same prefix, but have an incremental count after them?

From Explorer, select all the files that you want to bulk rename, right click, and select Rename.

While all of the files will be selected, only one is editable. Give the file a name, let’s pretend for the sake of discussion you typed ABC.jpg.

All of the rest of the files will be renamed ABC (1).jpg through ABC (n).jpg, where ‘n’ is the number of files minus one, since the first one doesn’t get a number.

Knowing this, you can do some clever stuff. Create one bogus file renamed to ZZZZZZZZ.TXT at the end of your list; select all the files, and bulk rename them as shown above. Then delete the bogus file, it should be the only one without a number, and you’ve just made a sequence of files.