There's some ideas on this subject in MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/h tml/tdlg_ch1.asp
Under "The Build Process" it recommends splitting the AssemblyInfo.cs file into bits that are shared between assemblies and bits that aren't. You then use SourceSafe to share the shared bits between the assemblies. There may be other useful tips in there, too :) G. -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of Scott Hanselman Sent: 29 April 2002 18:29 To: [EMAIL PROTECTED] Subject: Versioning and AssemblyInfo.cs Hey All, We have a complex ASP.NET application that consists of on 50+ ASP.NET pages 2 WebServices 4 Interop Libraries Several ASP.NET User Controls 200+ Unit Tests * Consequently there are 66 AssemblyInfo.cs files. * All of them are set to [assembly: AssemblyVersion("1.0.*")] for now. It's time to decide on a versioning scheme. We currently build the entire project from the commandline, including a fresh get from VSS, the build, the unit tests, and mailing the results to the team, using NANT (http://nant.sf.net) The WebServices will be versioned separately from the ASP.NET site itself, but I'd appreciate any thoughts or opinions on how to deal with assembly level versioning? * There are version labels in SourceSafe, do we simply edit each AssemblyInfo.cs manually? * Do I write an "Assembly" labeler to edit these for me? * Should it be a manual process or an automatic process? Secondarily, and tangentially related to versioning, has anyone implemented a SmartCard scheme for the enterprise-wide .NET PrivateKey for strong naming? I was hoping we'd do a DelaySign then use a SmartCard to sign the assemblies without the PrivateKey touching the harddrive. As always, your thoughts are appreciated, You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
