Search This Blog

19 June 2011

.Net 4.0 client profile not enough for the Dynamics Ax BC.Net

On Dilip's blog on Dynamics Ax, Dilip suggests in his article on BC.Net compatibility settings, to switch from .Net Framework 4.0 Client Profile to .Net Framework 3.5 with the argument, that this makes sense because the BC.Net is compiled on top of the .Net 3.5 Framework.
I was surprised reading this, because Microsoft promised backward compatibility and the .NET Framework 4:
The .NET Framework 4 is backward-compatible with applications that were built with the .NET Framework versions 1.1, 2.0, 3.0, and 3.5. In other words, applications and components built with previous versions of the .NET Framework will work on the .NET Framework 4.
The errormessage when compiling the BC.Net application against the .Net 4.0 client was:
...could not be resolved because it has a dependency on "System.Web....
So why do BC.Net projects don't compile with client profiles ? To answer this, browse through the BC.Net assembly with the .Net Reflector or, because it's open-source and free: ILSpy and you will notice that the BC.Net does reference for the BC.Net 2012 'Microsoft.Dynamics.AX.ManagedInterop' and this references the 'System.Web' assembly. The BC.Net 2009 does directly reference the 'System.Web'-assembly.
Now, having a look on Msdn for the .Net 4.0 client profile, it is documented:
The .NET Framework 4 Client Profile does not include the following features. You must install the .NET Framework 4 to use these features in your application:
  • Advanced Windows Communication Foundation (WCF) functionality
  • .NET Framework Data Provider for Oracle
  • MSBuild for compiling
The 'System.Web' assembly, which is part of the System.Web-namespace and so not part of the reduced .Net framework runtime, requires the full .Net 4.0 Framework. Now select the full .Net 4.0 Framework for compatibility and compile it again. It will work. Selecting the .Net 3.5 client profile will, of course, result in the same error. As I mentioned, this is true for the BC.Net of Dynamics Ax 2009 AND 2012.

UPDATED 02/07/2011: Dilip updated his article with a very interesting information about the runtime-compatibility of applications referencing the BC.Net assembly: It requires the useLegacyV2RuntimeActivationPolicy attribute to be set to true. But read his article fur further information.

UPDATED 17/112011: Dilips first article was about the error message during the compilation and I was referring to the compile-time compatibility that .Net4 guaranties. The updated article now is talking about the runtime-compatibility.
Anyway, the useLegacyV2RuntimeActivationPolicy is, despite of its name, not executing the application in a different CLR context (CLR2), but does translate some legacy shim APIs to the current CLR4, as explained in this great article about this attribute. So even by using this attribute we are, as promised by Microsoft, fully .Net 4 :-)


  1. Florian, I assume you didn't try out a working example with your theory, because even if you change it to 4.0 it still gives error, see my latest blog post on that

  2. Dilip, you are totally right to mention this. My point was, that the origin of the compiler-error was the 'client profile'-runtime with the missing ASP.Net part and not the .Net 4.0. This is why I didn't mention the startup property.

  3. Your all posts are nice. This is another blog which i get very useful for dynamics learner