<a href="http://www.micropoll.com/akira/mpview/585320-168921">Click Here for Poll</a><a href="http://www.questionpro.com" title="online surveys">Online Survey</a><BR> | <a href="http://www.micropoll.com" title="Website Polls">Website Polls</a><BR> | <BR><a href="http://www.micropoll.com/akira/MicroPoll?mode=html&id=168921">View MicroPoll</A></div>

Visual Studio 2010!

Read now >

Windows Mobile Development Thoughts

Read now >

View Now
DevSource RSS FEEDS
XML Want an easy way to keep up with breaking tech news? And the Get DevSource headlines delivered to your desktop with RSS.
ADVERTISEMENT
ADVERTISEMENT

 

DevSource.com: Your Source for Visual Studio on Facebook
ADVERTISEMENT
Ten Managed Application Pitfalls that Kill Version Compatibility
By John Mueller

Rate This Article: Add This Article To:

Ten Managed Application Pitfalls that Kill Version Compatibility - ' Strong Language '
( Page 4 of 5 )

6. Use Third-Party Products with Care

Third-party products can save considerable time and effort when developing an application. In addition, they are usually the most cost effective method for performing some tasks. For example, you might find a third party control provides everything you need, at a fraction of the cost of creating the same control yourself. However, third party products also come with hidden compatibility problems that you need to consider.

The biggest problem is the third-party products itself. Using a third-party product adds another layer of versioning to your application and could mean that you now have additional compatibility woes to consider. Interactions between different versions of .NET and the third party product can cause a number of problems; the resulting application might not even work.

Another issue to consider is the product's requirements. You might obtain a third-party product that requires the .NET Framework 1.1, yet your company might want to move on to version 2.0. At this point, you need to consider how best to proceed. In some cases, you could end up writing the controls that you initially relied on the third party product to provide, and the cost savings you had expected would vaporize.

7. Use Strong Names to Avoid Accidental Changes

Compatibility issues can extend into the accidental. For example, it's possible that damage to your application could go undetected until a user decided to try a specific application feature. Unfortunately, the .NET Framework doesn't detect this type of change unless you sign your application using a token. The process is quite simple.

  1. Create a key using the SN utility.
  2. Add the key name to your application's AssemblyInfo file using the [assembly: AssemblyKeyFile(")] attribute.
  3. Compile the application; signing occurs automatically.

8. Combine Modules as Needed to Ensure Application Integrity

Compatibility issues can crop up even if you had nothing to do with them. For example, someone can mix-and-match assemblies while trying to create a working setup. In fact, completely unrelated and unintentional events can conspire to create a compatibility problem in your application.

One approach to consider is combining all of the assemblies required to create a complete application. Using this technique means that the application is self-contained and that the user won't experience any problems using it. Of course, the approach you take to combining assemblies is important; you don't want to reduce the performance of the application either.

You can find a complete treatment of this topic in my article,


Discuss Ten Managed Application Pitfalls that Kill Version Compatibility
 
>>> Be the FIRST to comment on this article!
 


 
 
>>> More ASP and .Net Coding Techniques Articles          >>> More By John Mueller