Updater Application Block for .NET 2.0 Released

Wednesday, May 31, 2006 6:00:00 AM (GMT Daylight Time, UTC+01:00)
I was a bit surprised to see an update to the UAB released last week.  The reason I was surprised is that the release last year was supposed to be the final release… the qoute below is taken from the UAB 2.0 documentation.
 
"An updated version of the Updater Application Block that uses Enterprise Library June 2005 will soon be available. Following this, there are no plans for another release of the Updater Application Block. The .NET Framework 2.0 and Visual Studio 2005 include a new deployment technology, named ClickOnce, to address these same technical challenges. Better alignment to this new technology was one of the main design goals for this release."
 
Although there was no feature enhancements I am glad to see they updated the application block to .NET 2.0 and fixed some bugs.  In addition, with Enterprise Library 2006 for .NET 2.0 you can now consolidate the configuration files, which is really a pain in the previous version of the Enterprise Library.
 
Eugenio Pace posted the release notes on his blog.
 
 

Posted in TidByte |Comments [0]     

Intellisense for SQL Analyzer

Wednesday, May 31, 2006 6:00:00 AM (GMT Daylight Time, UTC+01:00)
Redgate software has added intellisense to the SQL Analyzer.  Looks like you can download for free until September 1st, 2006.  You can get the downloa at http://www.red-gate.com/products/SQL_Prompt/index.htm.
 
Here is a sample of what it looks like.
 
Intellisense for SQL Server

Posted in Development |Comments [0]     

Naked Conversations

Friday, May 19, 2006 4:45:45 AM (GMT Daylight Time, UTC+01:00)

I just finished Naked Conversations, very interesting book about blogging and business.  If you blog, I would suggest reading it.  I bought it yesterday, started reading on a flight to Chicago and finished it on the way back.

 

One of the things that I found interesting and guess never realized was that blogging is taking off at an incredible rate and the consumption of Podcasts is taking off at a even a greater rate then blogging.  I think this is due to two reasons.  The activity of listening to Podcasts can be secondary to what you are doing.  When reading a blog you are pretty much single threaded, focused on the content of the blog.

 

The downfall to Podcasting is that it takes more investment to get into, both from a monetary standpoint and time.  These factors limit the number of Podcasters, which if the demand continues to rise for Podcasts may create somewhat of a shortage… and may actually create a viable market for subscription based podcasts.

 

Blogcasting?? So this brings us to the next point.  Why aren’t we recording blog entries and publishing them. Just recording what we wrote.  Some would suggest this would be a great application for the Microsoft Speech SDK.  The problem with this is the best digital voices still sound digital.  Even the AT&T voices still sound too robotic in my opinion. 

 

 

Posted in TidByte |Comments [0]     

Compatibility between 1.1 and 2.0 Framework

Sunday, May 14, 2006 6:00:00 AM (GMT Daylight Time, UTC+01:00)
Playing around with some of the .NET 2.0 framework and here are some interesting things to note.
 
IPC Channel
There is a new bidirectional IPC Channel (System.Runtime.Remoting.Channels.Ipc ) with the .NET Framework 2.0 that does not use the network layer when communicating between AppDomains.  This equates to increased performance for applications communicating between each other on the same machine.
 
BinaryFormatter/SoapFormatter and CLR Backward Compatibility
If you have a need to remote between the 1.1 and 2.0 versions of the .NET Framework and are using the BinaryFormatter, a patch will be required for the 1.1 framework, that will allow it to communicate with 2.0 (http://blogs.msdn.com/eugeneos/archive/2006/03/15/552315.aspx).  This is mostly do to the fact that minor changes (adding extra fields for example) to types serialized by the BinaryFormatter are considered breaking changes in 1.1.  It looks like with the introduction of the Version Tolerant Serialization ( http://msdn2.microsoft.com/en-us/library/ms229752.aspx) a similar patch will not be required to go from 2.0 to the next revision of the framework.  This patch is not applicable to the SOAP formatter, since the SoapFormatter implements a less stringent type checking which allows the addition of fields with out breaking serialization.  This would also indicate the importance of the SoapFormatter has been reduced and there would be very few benefits for using it over the BinaryFormatter and the introduction of Version Tolerant Serialization.
 
Serialization of Generics
The SoapFormatter does not support serialization of Generics, however the BinaryFormatter does. http://blogs.msdn.com/mattavis/archive/2004/08/23/219200.aspx  Another reason to move away from the SoapFormatter for .NET to .NET implementations.
 
CLR
Recently while working on a project for a client we discussed how upgrades were going to work for the application.  This eventually evolved into a discussion of how updates to the framework would come into play with the application.  These are my findings.  When I refer to 1.0, 1.1 or 2.0 I am referring to the version of the .NET Framework.
 
Using a newer version of the CLR to load assemblies compiled in older versions is generally OK, because of the .NET Frameworks commitment to being backwards compatible.  Instances can arise where the older implementation will fail to work, and those have been documented at: Breaking Changes from Version 1.1 to 2.0 (http://msdn.microsoft.com/netframework/programming/breakingchanges/default.aspx). 
 
Currently I am using the July 2005 Application Blocks compiled in 1.1 with the .NET 2.0 implementation without a problem.
 
Loading Assembly Changes
It is possible to load a 1.1 assembly into a 1.0 application.  It is also important to note that the 2.0 CLR will not allow you to load an assembly built with 2.0 into a process that is running the 1.0 or 1.1 .NET Frameworks
 
Framework Resolution
It is possible to run an application compiled for the 2.0 Framework, and have that application consume assemblies built in 1.0,1.1 and 2.0.  The important thing to understand is that the process will redirect all references to the version of the CLR that is loaded into the process.  This allows types to be shared among all the different versions of the assemblies.  For example, a reference to a System.Xml.XmlDocument in .NET Framework version 1.1 can be consumed by .Net 2.0 application with out any problems.  Since it is possible that there may be undiscovered issues with this default behavior of the CLR you can override this capability in the configuration file and tell the 1.1 assembly to bind to the 1.1 version of System.Xml.XmlDocument.  However, if you try to communicate with any other assemblies that were not compiled in the 1.1 framework the CLR will throw an exception.
 
Some interesting links related to  framework capatibility.
 
CLR 2.0 Compatibility and Side by Side (Brad Abrams Blog)
 
Targeting a .NET Framework Version
 
 

Posted in Development |Comments [0]