XmlSerializer: Changes from .NET4 to 4.5

As I wrote in one of my last post (XmlSerializer bug in .NET4.5 and legacy serializer) was the XmlSerializer completely redesignd and rewritten in .NET 4.5. This leads to several problems (see my last post).

Also it leads to problems if you use a newer development environmen as you have supported environments in the field. Especially if your application must support .NET4 and you use for development a later VS version (>2010). In this case you might use indirectly Features, which are not available in a pure .NET4 environment. One of the feature affects serialization of “lists”.

Here is a small example, which works perfectly in .NET4.5 and later, but fails with .NET4:

using System.Collections.Generic;
using System.Xml.Serialization;
namespace ConsoleApplication
    public class Program
        public Program() { Persons = new List<Person>(); }
        static void Main()
            var ser = new XmlSerializer(typeof(Program));
            var r = new System.IO.StringReader("<Program><Persons><Person><Name>TEST</Name></Person></Persons></Program>");
        public List<Person> Persons { get; private set; }
    public class Person
        public string Name { get; set; }

Starting this with a computer having only .NET4 will lead to the following error message during generation of the XmlSerializer:

Unbehandelte Ausnahme: System.InvalidOperationException: TemporΓ€re Klasse kann nicht generiert werden (result=1).
error CS0200: Property or indexer 'ConsoleApplication.Program.Persons' cannot be assigned to -- it is read only
error CS0200: Property or indexer 'ConsoleApplication.Program.Persons' cannot be assigned to -- it is read only

   bei System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
   bei System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
   bei System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
   bei System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace)
   bei System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
   bei ConsoleApplication.Program.Main() in ...\ConsoleApplication6\Program.cs:Line 12.

So what is the problem here in .NET4?

It seems that if there is a setter available (regardless of private or public), the serializer will try to use it… you can even test it with a newer .NET Version, by using the “legacy XmlSerializer” in your “app.config”:

    <add key="System:Xml:Serialization:UseLegacySerializerGeneration" value="true" />

Solution: Just remove the setter from the property “Persons” and it works in .NET4 and .NET4.5 and later:

using System.Collections.Generic;
using System.Globalization;
using System.Xml.Serialization;
namespace ConsoleApplication
    public class Program
        public Program() { Persons = new List<Person>(); }
        static void Main()
            var ser = new XmlSerializer(typeof(Program));
            var r = new System.IO.StringReader("<Program><Persons><Person><Name>TEST</Name></Person></Persons></Program>");
        public List<Person> Persons { get; }
    public class Person
        public string Name { get; set; }

XmlSerializer bug in .NET4.5 and legacy serializer

Starting with .NET4.5 (which is an in-place update of .NET4) Microsoft created a completely new XmlSerializer. And as a developer you know, that it is almost impossible to re-write a software and match the whole features of the original software.
But Microsoft was sure, that the new implementation is not only faster, but will also replace the old XmlSerializer for almost all cases… that was the reason why Microsoft are using the new implementation by default. This is even true, if you only have shipped your app with .NET4 and a different program installs the .NET4.5 update on the computer… then your old programm will also use the new XmlSerializer…

And my (simple) program fails in that case! If I want to serialize an object, if throws and System.InvalidProgramException exception ;(

using System.ComponentModel;
using System.IO;
using System.Xml.Serialization;

namespace ConsoleApplication1
  public class Program
    static void Main()
      new XmlSerializer(typeof (Program)).Serialize(new StringWriter(), new Program());

    public decimal Value;

What is now the problem? For me it seems very normal… The problem is, that I used a “DefaultValue”, which is a “double” and a field which is a “decimal”. With the old XmlSerializer this was no problem… internally the conversion was done correctly. But it seems that the new one, now tries to assign the double to the decimal and fails

Now there are two possibilities to solve this problem:

  1. Replace “0.0” with “0” which leads to an interger (int) and this can be assigned to a decimal
  2. Enable the old bahavior again πŸ˜‰

Microsoft also knew about the impossibility to replace an old component with a new one, which exactly the same behavior πŸ˜‰ Therefor you can enable the old XmlSerializer via app.config:

    <xmlSerializer useLegacySerializerGeneration="true"/>

But there is a big warning in the knowledgebase article: “We do not recommend that you apply this workaround on a computer that is running a version of the .Net framework that is earlier than the .Net framework 4.5.”

So if you want to ship your application with the old behavior and you are not sure that .NET4.5 is installed, then you should use the following app.config entry, which works in .NET4 and 4.5 πŸ˜‰

    <add key="System:Xml:Serialization:UseLegacySerializerGeneration" value="true" />

Of course, I have choosen the first optional and have replaced “DefaultValue(0.0)” with “DefaultValue(0)”. Lukily, we had no decimal places πŸ˜‰

Why NOT to use a “TFS local workspace”

If you use VS2013 (with TFS2013) your VS suggest to use a local TFS Workspace.

At the first view, this seems to be a good idea… but after a depper look there seems to be a bad implementation, at least in this Version.

The main disadvantages are:

  • If you want to use multiple VS2013 instances at the same time (This is a show-stopper for me); quote from Microsoft: “it is more likely to cause problems if you are using a local workspace” (by the way: It is also not supported with a server-workspace; but I never have seen any problems)
  • If you want to use VS2010 within the same workspace
  • If you want to see, which team member has checked-out a file (this is not possible for local workspaces, because there is no “check-out”)
  • If you want to enforce “check-out lock”; especially in small teams, this is a good idea, to prevent merges.
  • If you want to use “Enabled get latest on check-out” (because there is no check-out…)
  • If your workspace contains many files (or Versions of files), then it uses a hughe amount of space to use the local workspace (ok, this is by design and cannot be changed; the same is true for git). Microsoft recommends a local workspace only for less than “100,000 items” (means files and versions).

For more info see also: Decide between using a local or a server workspace

ADC++ 2014 – Debugging Tools For Windows

Here you will find the presentation and the demos from the session at Advanced Developers Conference C++ in Garching. I hope that you enjoyed it and can use some of the features I showed to you!

And please give your feedback for the session, if you have not done yet: http://www.adcpp.de/feedback/sessions.aspx

Presentation: ADC++2014_JochenKalmbach_DebuggingToolsForWindows_public.pdf (2,62 MB)

Demos: ADC2014_demos.zip (187 MB)

Just a note to the demos: You must install the Debugging Tools For Windows from the Windows SDK and copy the “Debuggers” Directory into “ADC2014”! Then all examples should work.

If you have any questions, just drop a comment…

Change Target-Framework in C++/CLI for VS2010/2012

It is still not possible to change the target framework in the VS2010 or VS2012 IDE in the project settings.
The only way to change it, is to manually edit the vcxproj file. For this you need to do the following:

  1. Right-click on the projectin Solution Explorer and select “Unload project”
  2. The again do a right-click on the unloaded project in the Solution Explorer and select “Edit .vcxproj”
  3. In the porject XML file search for the node
  4. In this node, find the sub node (if it does not exists, you must add one)
  5. The inner text of this node defines the target framework version. It can be one of the following values: v2.0,v3.0, v3.5 v4.0 (VS2010 and 2012) or v4.5 (only VS2012)
  6. Save the vcxproj Datei and close it
  7. The again do a right-click on the unloaded project in the Solution Explorer and select “Reload Project”


  <PropertyGroup Label="Globals">

Auto completion for current directory

Since Windows 200 it is possible to have auto completion for edit boxes which searches the file system and presents a drop down list with the current files. There is a simple helper function to enable this feature: SHAutoComplete

But this function only offers a simple interface to the more complex COM interface IAutoComplete.

While the “SHAutoComplete” is sufficent, it will not work if you want to have auto completion for files in the current directory. For this feature, you need to use the native COM interface:
For more info see also: Using Autocomplete

Here is an example of enabling auto completion for the file system, including the current directory:


HRESULT EnableAutoCompleteWithCurrentDirectory(HWND hWndEdit)

  IAutoComplete *pac;
  HRESULT hr = CoCreateInstance(
    __uuidof(pac), reinterpret_cast<void**>(&pac));
  if (FAILED(hr))
    return hr;

  IUnknown *punkSource;
  hr = CoCreateInstance(
    __uuidof(punkSource), reinterpret_cast<void**>(&punkSource));
  if (FAILED(hr))
    return hr;

  // Get current directory
  wchar_t szCurDir[MAX_PATH];
  GetCurrentDirectoryW(MAX_PATH, szCurDir);

  IACList2 *pal2;
  hr = punkSource->QueryInterface(__uuidof(pal2), reinterpret_cast<void**>(&pal2));
  if (SUCCEEDED(hr))
    if (acloOptions != ACLO_NONE)
      hr = pal2->SetOptions(acloOptions);

    ICurrentWorkingDirectory *pcwd;
    hr = pal2->QueryInterface(__uuidof(pcwd), reinterpret_cast<void**>(&pcwd));    
    if (SUCCEEDED(hr))
        hr = pcwd->SetDirectory(szCurDir);


  hr = pac->Init(hWndEdit, punkSource, NULL, NULL);

  if (acoOptions != ACO_NONE)
    IAutoComplete2 *pac2;
    HRESULT hr2 = pac->QueryInterface(__uuidof(pac2), reinterpret_cast<void**>(&pac2));
    if (SUCCEEDED(hr2))
        hr2 = pac2->SetOptions(acoOptions);

  return hr;

You can enable the auto completion for a control by calling this function:


Improved “PreventSetUnhandledExceptionFilter”

Starting with VS2005(VC8) it was not possible to handle all exceptions in process. I have discussed this in “SetUnhandledExceptionFilter” and VC8 and in Unhandled exceptions in VC8 and above… for x86 and x64.

It seemms that the code I posted had been used in many Projects to handle all exceptions and to write a minidump in that case. Also someone has used it in a VB6 application and for this he needed to implement this function in a separate “CrashHandler.dll”. But now he got errors during the shutdown of the VB6 application. It seems that VB6 unloads the DLL before other DLLs and it seems that some other DLL is calling “SetUnhandledExceptionFilter” during shutown. This now leads to trouble, because the DLL is already unloaded.

Now I created a better and cleaner implementation for the “PreventSetUnhandledExceptionFilter” function, which also works in any situation, even if the DLL was unloaded πŸ˜‰

static BOOL PreventSetUnhandledExceptionFilter()
  HMODULE hKernel32 = LoadLibrary(_T("kernel32.dll"));
  if (hKernel32 == NULL) return FALSE;
  void *pOrgEntry = GetProcAddress(hKernel32, "SetUnhandledExceptionFilter");
  if (pOrgEntry == NULL) return FALSE;

#ifdef _M_IX86
  // Code for x86:
  // 33 C0                xor         eax,eax  
  // C2 04 00             ret         4 
  unsigned char szExecute[] = { 0x33, 0xC0, 0xC2, 0x04, 0x00 };
#elif _M_X64
  // 33 C0                xor         eax,eax 
  // C3                   ret  
  unsigned char szExecute[] = { 0x33, 0xC0, 0xC3 };
#error "The following code only works for x86 and x64!"

  SIZE_T bytesWritten = 0;
  BOOL bRet = WriteProcessMemory(GetCurrentProcess(),
    pOrgEntry, szExecute, sizeof(szExecute), &bytesWritten);
  return bRet;

ANN: Community Forums NNTP Bridge

After looking deeper into the MSDN Forums Client and into an C# NNTP server, I decided to integrate both Ms-PL projects into a single project:

Community Forums NNTP bridge

The result is a single “Community Forums NNTP Bridge” which can replace the MS NNTP Bridge. It also integrates both web services (*social*, *answers*) into a single NNTP server; so the “feeling” is like before the split πŸ˜‰

If you are interested, you can take a look (with full source code) into the alternative:

Converting VC projects to VC2010: Warning MSB8012

If you convert a project from VC5/6/2002/2003/2005/2008 to VC2010, you will sometimes get an warning during the conversion (UpgradeLog.XML) and during the link phase os your build. This warning might look like:

1>...Microsoft.CppBuild.targets(990,5): warning MSB8012: 
  TargetPath(...LeakFinder_VC9.exe) does not match the Linker's OutputFile property value (...LeakFinder.exe). 
  This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).


1>...Microsoft.CppBuild.targets(992,5): warning MSB8012: 
  TargetName(LeakFinder_VC9) does not match the Linker's OutputFile property value (LeakFinder). 
  This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

The problem is, that the following two settings are not identical (Target Name, Target Extension):

and (Output File):

If you match those two, the warning will be gone πŸ˜‰

For example, if you have named your EXE in Debug-Builds: “MyAppd.exe” and in Release-Builds “MyApp.exe”, I suggest that your only change the “Target Name” in the General-Page to “MyAppd” (for Debug) and “MyApp” (Release) or ($(ProjectName) if it is the same name as the project).
Then you must also change the “Linker | General | Output File” to the default setting: “” or “$(OutDir)$(TargetName)$(TargetExt)”. This setting is always suggested!

If you want to change the output directory, you should the the “General | Output Directory” setting.

More info about this conversion problem can be found here:
Visual Studio 2010 – $(TargetName) macro
Visual Studio 2010 C++ Project Upgrade Guide

OleView not found in VS2008 and VS2010

If you have installed VS2008 and/or VS2010 (full), you will notice that OleView is not installed!
The product team decided to remove this utility from the tools-folder.

But you the source-code is still available! You can find it under

C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\Samples\\1033\\VC2010Samples.zip

Extract the files and build (the release version of)


Then you have the two files: oleview.exe and iviewers.dll

Also, the same problem is with the OLE-Test Container (tstcon). This application can also be found in the samples.
See also: ActiveX Test Container Application is Still Available

Supported runtime OS for VC2010

Here is now the offical statement for the supported runtime OS:

  • Windows XP with SP2 and later
  • Windows Server 2003 with SP1 and later
  • Windows Vista RTM an later
  • Windows Server 2008 RTM and later
  • Windows 7 and later

This restrictions comes from a security desicion to have a hard dependency on EncodePointer, which is only available in the above OSes.

For more info see: Visual Studio 2010: Windows Platforms (CRT)

Better sos.dll for debugging in WinDbg available!

Finally MS release a *better* sos.dll extension for WinDbg (psscor2.dll), which has many more features. One of my favorite feature is “displaying callstacks with line infos”!

Also it has a good “!Analysis” command for dump-files.

The output of “!Help” is:

PSSCOR is a debugger extension DLL designed to aid in the debugging of managed
programs. Functions are listed by category, then roughly in order of
importance. Shortcut names for popular functions are listed in parenthesis.
Type "!help " for detailed info on that function. 

Object Inspection                  Examining code and stacks
-----------------------------      -----------------------------
DumpObj (do)                       Threads
DumpArray (da)                     CLRStack
DumpStackObjects (dso)             IP2MD
DumpAllExceptions (dae)            BPMD
DumpHeap                           U
DumpVC                             DumpStack
GCRoot                             EEStack
ObjSize                            GCInfo
FinalizeQueue                      EHInfo
PrintException (pe)                COMState
DumpField (df)
DumpDynamicAssemblies (dda)
DumpColumnNames (dcn)

Examining CLR data structures      Diagnostic Utilities
-----------------------------      -----------------------------
DumpDomain                         VerifyHeap
EEHeap                             DumpLog
Name2EE                            FindAppDomain
SyncBlk                            SaveModule
DumpThreadConfig (dtc)             SaveAllModules (sam)
DumpMT                             GCHandles
DumpClass                          GCHandleLeaks
DumpMD                             VMMap
Token2EE                           VMStat
EEVersion                          ProcInfo 
DumpModule                         StopOnException (soe)
ThreadPool                         MinidumpMode 
DumpHttpRuntime                    FindDebugTrue
DumpIL                             FindDebugModules
PrintDateTime                      Analysis
DumpDataTables                     CLRUsage
DumpAssembly                       CheckCurrentException (cce)
RCWCleanupList                     CurrentExceptionName (cen)
PrintIPAddress                     VerifyObj
DumpHttpContext                    HeapStat
ASPXPages                          GCWhere
DumpASPNETCache (dac)              ListNearObj (lno)
DumpMethodSig                      Other
DumpRuntimeTypes                   -----------------------------
ConvertVTDateToDate (cvtdd)        FAQ
ConvertTicksToDate (ctd)
DumpXmlDocument (dxd)
DumpCollection (dc)

Examining the GC history

Major bug in the new dbghelp.dll

The latest dbghelp.dll (version, which can be downloaded via the newest WDK, seems to have a major bug regarding the function SymGetModuleInfo64 (which is used in almost every project, if you want to display module-infos).

A user reported this bug in the WinDbg newsgroup.

I now build a small repro-code, which shows the problem. You can download the code here: dbghelp_bug_6.12.2.633.zip

The problem is, that the size of the struct “IMAGEHLP_MODULE64” has changed. They added two DWORDs at the end (the struct has now a size of 0x690 bytes). This is normally not a problem because the struct has a “SizeOfStruct” member, which must be set, prior to calling the “SymGetModuleInfo64” function.

But the new version does not support the older version of the struct with a size of 0x688 bytes, which is commonly used because this was the last version since 2003!!! It only supports the older versions from 2002 and before.

So I hope that this major bug will soon get fixed… but after the WinDbg-Release seems to be coupled to the WDK-release, we can wait until next year…

Forums NntpBridge and DateTime

There is a “research” project to access the msdn-web forums via a nntp-bridge. The offical version is “V1″… but I must say, that it is still Beta1 πŸ˜‰

For example, there is a bug with the DateTime-Format, which uses the current system locale… This bug was reported severaly months ago, and nothing happend… In january and february it was not a problem, because “Jan” and “Feb” are the same in english and german… but in “MΓ€rz” the NntpBridge started to report all postings with “01.01.1970 01:00″… because it will report the date as “Mrz” instead of “Mar”… which is somehow bad…

So I decided to make a quick fix for this behavior. You just need to add the System.Globalization.CultureInfo.InvariantCulture as parameter to the ToString method.

Here are the steps, how you can fix this by yourself:

  1. Locale the directory of the Nntp-Bridge (normally “C:\Program Files (x86)\Microsoft Community Tools\Microsoft Forums NNTP Bridge”
  2. Copy the file “nntp.dll” to “nntp_org.dll” so you have the original version saved
  3. Copy “nntp.dll” into a temporary directory like “c:\temp\nntp_fix”
  4. Open a “Visual Studio 2005/2008 Command Prompt (x86)”
  5. Go to the temporary directory (cd /D c:\temp\nntp_fix)
  6. Disassemble the nntp.dll
    ildasm nntp.dll /out=nntp.il
  7. Now you need to change the content of the nntp.il file
  8. Find the method “GetMessageFormat” and change it from
    .method public hidebysig static string  GetMessageFormat(valuetype [mscorlib]System.DateTime dateTime) cil managed
      // Code size       28 (0x1c)
      .maxstack  8
      IL_0000:  ldstr      "{0} {1}"
      IL_0005:  ldarga.s   dateTime
      IL_0007:  ldstr      "ddd, d MMM yyyy HH:mm:ss"
      IL_000c:  call       instance string [mscorlib]System.DateTime::ToString(string)
      IL_0011:  ldsfld     string Nntp.NntpTimeUtility::GmtTimeZoneOffset
      IL_0016:  call       string [mscorlib]System.String::Format(string,
      IL_001b:  ret
    } // end of method NntpTimeUtility::GetMessageFormat


    .method public hidebysig static string  GetMessageFormat(valuetype [mscorlib]System.DateTime dateTime) cil managed
      // Code size       33 (0x21)
      .maxstack  8
      IL_0000:  ldstr      "{0} {1}"
      IL_0005:  ldarga.s   dateTime
      IL_0007:  ldstr      "ddd, d MMM yyyy HH:mm:ss"
      IL_000c:  call       class [mscorlib]System.Globalization.CultureInfo [mscorlib]System.Globalization.CultureInfo::get_InvariantCulture()
      IL_0011:  call       instance string [mscorlib]System.DateTime::ToString(string,
                                                                               class [mscorlib]System.IFormatProvider)
      IL_0016:  ldsfld     string Nntp.NntpTimeUtility::GmtTimeZoneOffset
      IL_001b:  call       string [mscorlib]System.String::Format(string,
      IL_0020:  ret
    } // end of method NntpTimeUtility::GetMessageFormat
  9. Then compile the nntp.dll again (and delete the original dll before compiling (del nntp.dll)):
    ilasm /dll nntp.il /resource=nntp.res
  10. Now you can copy the patched nntp.dll into the original directory (be sure, the application is not running).

Now it looks better:

That’s all! Happy NntpBridging πŸ˜‰