UPDATED - January 7th 2009
This Blog Post is not completely Up to date since a Redistributable is now available which can enable you to have a "single" .NET 2.0 SP2 Package.
.NET Framework 2.0 SP2 is now available here : http://msdn.microsoft.com/en-us/vs2008/bb898654.aspx
____________________________________________________________________________________________________________________________
With the advent of .NET Release pace, I often encounter customers lost with .NET Framework version issues and Services Pack Mix.
I always point them to this blog post (in French…) http://blogs.msdn.com/aurelien/archive/2008/09/23/le-multi-targeting-de-visual-studio-et-les-services-packs.aspx
The one question I especially this one :" Where can I Download Microsoft .NET 2.0 SP2 ?"
Currently (December 2008), the installation package of .NET 2.0 SP2 is not available as a "standalone" package.
.NET Framework 2.0 SP2, actually ships with .NET Framework 3.5 SP1. The only way to get the former is to get the latter.
So the Answer is (to date) : install .NET Framework 3.5 SP1.
This however raises a question for customer running .NET 2.0 applications in a "Closed" (meaning not connected to either Windows Update, or to the Internet).
These customer uses to be able to install their application without needing to have an Internet Connection. It is still possible, but there is some guidance to be aware of in the Process.
From .NET 3.5 to .NET 3.5 SP1
http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe
From Anywhere to .NET 3.5
- Either use the Boostraper which will download missing requirements : dotnetfx35setup.exe here :
http://www.microsoft.com/downloads/details.aspx?familyid=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en
- Or Use the Full Installation Package dotnetfx35.exe here :
http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe
If you plan to use the Full Installation Package, be aware that there is a bunch of Pre-Requisite that .NET 2.0 customer may not even know about.
Such as :
- Software Rasterizer for the Microsoft DirectX 9.0 Software Development Kit (SDK).
- Or XML Paper Specification (XPS) Shared Components Pack 1.0
The good thing is that a very useful Deployment Guide is available and will definitely help in this task:
.NET Framework 3.5 Deployment Guide for Administrators
http://msdn.microsoft.com/en-us/library/cc160717.aspx
That said, if you plan to deploy .NET 2.0 SP2 on you master, using Windows Update (or your internal WSUS) would ease the process.
Web Application Projects (WAP) are a great feature that has been in the field for a while, but which will progressively appear more and more due to its presence in Visual Studio 2005 SP1.
Recently, I had to automate the deployment of a WAP.
To my surprise, there is not easy way to do it in a clean manner.
Publish Wizard in Visual Studio 2005 is great : It copies only the necessary files.
But How Achieve the same Results with Command Line Scripts ? No so straightforward.
Web Deployment Projects (WDP) were the immediate Answer.
Unfortunately, have a limitation of WDP with WAP : the Deployed project contains useless file that should NOT appear in the published location; such as *.csproj, *.csproj.user, *.sln.
Even if you loose the opportunity to precompile the site (remove code in aspx files), merge assemblies, (…) , it appeared to me as a better option not to use WDP.
What is the solution then ?
The solution is to use a "Hidden" target of WebApplication Target.
The target file is located at :
C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets
This file contains the definition of the Target available with WebApplication Project.
_CopyWebApplication enables to copy the WebSite in specific location.
Yet another limitation comes : referenced Dll within the WAP are not copies in the target Bin directory.
A workaround is to
- Compile the site
msbuild WebApplication1.csproj /p:Configuration=Release
- Copy all assemblies in the target Bin directory
Robocopy.exe bin\ ..\_PublishedWebsites\WebApplication1\bin\ XF *.dll
- Call the _CopyWebApplication target
msbuild WebApplication1.csproj /target:_CopyWebApplication /property:OutDir=..\ /p:Configuration=Release
You finaly end up with the compiled site, with all and only what you need.
Team Foundation Server is a great Product.
No matter how great it is, the same questions do arise on any large scale development project I face, with any SCM & Build tool :
- How to manage dependencies between teams?
- How to deal with versioning and versions dependencies ?
Here are some simple rules & trick that we found appropriate to use with TFS:
- Dependencies within VS Projects in a Solution are “Project Dependencies”
- Dependencies between VS Projects within different Solutions within the same Team Project are Binaries Dependencies handled with an M: Drive (subst) that points to a local Binary Repository.
- Build Configuration within a Team Project deal manually with the build order.
- Dependencies between Projects within different Team Projects are Binaries Dependencies (Same with M drive).
Developers have an M: Drive mapped to a local copy of the repository.
Most dependencies reference the LATEST version (except in some cases where the explicitly reference a Released version ex : 1.0)
Developers work with their local copy. When the version is stable, that can update their local Repo with a script from the repository (robocopy), an build again ( with the latest build assemblies).
Comments on this are more than welcome.
I recently faced a situation in which a customer had to interoperate between a Visual Basic 6 application and existing WebServices. Interesting challenge, with many different options.
The following direction were foreseen as follows :
- Use XMLHTTP an code SOAP call and serialization by hand
- Using SOAP Toolkit : it is deprecated by the Framework .NET and support policy sticks to the issue of the Extended Support lasting until March 31, 2008
- Using .NET assemblies on the client called by VB6 components through COM Interop, thus leveraging the ability of .NET to easily deal with WebServices (Proxy generation, Serialization)
- Using Liquid XML http://www.liquid-technologies.com/default.aspx
A solution that "mimics" VB6/COM world what VS & .NET do : class generation & handling serialization
Finaly an interesting alternative was seen. The existing applicaiton was already using a COM+ middle tier. So the solution used was the following ;
- Use a COM+ .NET Enterprise Services Middle tier component that
- Make the WebService call
- Deserialize the objets into .NET Structs
- Pass by value the objects back to the VB6 Client using DCOM, and marshalling the Struct byValue.
And it works !
Interesting integration Pattern to reuse to call WebServices from a VB6 Application that cannot sustain .NET framework on the client station.
