Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

What's New in .NET 2.0 for Assemblies and Versioning? : Page 4

.NET 2.0 and Visual Studio 2005 have numerous innovations regarding assemblies and versioning. You can add a reference to an EXE assembly, resolve type conflicts by aliasing a reference, given permission, you can access the internal types of another assembly, protect and manage with ease your strong name keys, insist on building against a specific version of an assembly, and target specific CPU architectures.


advertisement
CLR Versioning
If the application doesn't indicate to .NET which CLR versions it requires, the application is actually telling .NET that any compatible CLR version is allowed. In that case, .NET detects the CLR version the application was compiled with and uses the latest compatible CLR version on the machine. To that end, .NET is aware of which CLR version is backward-compatible with other versions; presently however, Microsoft considers all newer .NET versions to be backward-compatible.

Note that CLR backward compatibility is not the same as forward compatibility. Backward compatibility deals with the question of "Can an old CLR version assembly execute against a newer CLR version?" Forward compatibility deals with "Can an assembly that was built against a newer CLR version execute on an old CLR version?" Backward compatibility is mostly the product of changes to type definition and type behavior. Forward compatibility is governed by the metadata version. Both .NET 1.0 and .NET 1.1 have the same metadata version, and so they are both backward and forward compatible with respect to each other. .NET 2.0 has a new metadata version, and as a result it is only considered backward compatible—.NET 2.0 assemblies require the .NET 2.0 runtime.

Table 1 depicts CLR version compatibility. The left column lists the CLR versions an assembly was built against and the rest of the columns list whether it can run against a particular CLR version. Note that Visual Studio 2005 can build only applications targeting CLR version 2.0.

Table 1: CLR version compatibility.



Assembly\CLR

1.0

1.1

2.0

1.0

+

+

+

1.1

+

+

+

2.0

-

-

+


Assemblies and CPU Architectures
In theory, any IL-based assembly could run on any target CPU because of the two-phase compilation process. If the IL has nothing in it that pertains to specific CPU architecture or machine languages, then the JIT compiler will generate the machine instructions for the target CPU at run time. However, in practice, it is possible to write un-portable assemblies. For example,
 
Figure 7: Specifying CPU architecture for your assembly.
C# lets you explicitly dictate the memory layout of structures. If you use explicit x86 memory layout, your code will not work on Itanium or any other 64-bit machines. In addition, if the assembly imports legacy COM objects, then the assembly will not work on 64-bit machines, because 64-bit Windows does not support COM natively. For that, your assembly will have to execute in the Win32 emulation environment (known as WOW, or Windows-on-Windows). However, if you simply load that assembly on a 64-bit Windows machine, it will run in the native 64 environment, not the WOW.

The only solution for such CPU-specific assemblies is to incorporate the information on the target CPU into the binary executable that contains the assembly. That way, if an assembly which requires the 32-bit WOW emulation is loaded on a 64-bit machine, the loader will launch it in the WOW, whereas the 32-bit JIT compiler will compile it correctly. In case you develop an assembly that requires a particular CPU architecture, you need to inform Visual Studio 2005 about that CPU so that it could incorporate the information into the binary.

In every project in Visual Studio 2005 in the Build tab under the project properties you'll find the Platform Target drop down list (see Figure 7). The default is AnyCPU, but you can select x86, x64 or Itanium. When specifying a particular CPU, you are guaranteed that the assembly will always execute on that CPU architecture (or an emulation of it).



Juval Lowy is a software architect and the principal of IDesign, Inc., a consulting and training company focused on .NET architecture consulting and advanced .NET training. His latest book is "Programming .NET Components, 2nd Edition" (O'Reilly, 2005). Juval is a frequent presenter at development conferences and Microsoft's Regional Director for the Silicon Valley. Over the last two years Juval has been part of the Indigo Strategic Design Review process. Microsoft recognized Juval as a Software Legend as one of the world's top .NET experts and industry leaders. Contact him at www.idesign.net
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap