|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
URGENT | Framework version problemThe problem that comes up is really complex. We have certain controls that behave in contrasting fashions if run on different machines (having different versions of the f/w). Not only that, at times i even end up getting certain build errors like: Error: The dependency 'Managers, Version=1.0.2130.17591, Culture=neutral' in project 'PresentationValidators' cannot be copied to the run directory because it would conflict with dependency 'Managers, Version=1.0.2125.39306, Culture=neutral'. Moreover, this problem also creeps up very randomly, so we can't even reproduce it if wanted, at will. The versions we currently have are: 1.1.4322.573 and 1.1.4322.2032 Could somebody please shed some light on what can be done now? Cheers! Nick Nick wrote:
Show quote > those are the same version, with different file versions. THe assembly> We currently have 2 versions of the 1.1 framework being used in our > project. The problem that comes up is really complex. We have > certain controls that behave in contrasting fashions if run on > different machines (having different versions of the f/w). Not only > that, at times i even end up getting certain build errors like: > > Error: The dependency 'Managers, Version=1.0.2130.17591, > Culture=neutral' in project 'PresentationValidators' cannot be copied > to the run directory because it would conflict with dependency > 'Managers, Version=1.0.2125.39306, Culture=neutral'. > > Moreover, this problem also creeps up very randomly, so we can't even > reproduce it if wanted, at will. The versions we currently have are: > 1.1.4322.573 and 1.1.4322.2032 versions are the same, 1.0.5000.0 The problem you're running into is with your own code, signed assemblies. If possible, use a different buildnumber scheme, like 1.0.0.0, and manually increase that number when necessary and use assemblyfileversion to crank up the fileversion number with each build. This way your users can store a single version in the gac, the latest fileversion, and be happy. FB -- ------------------------------------------------------------------------ Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#) ------------------------------------------------------------------------ Frans,
Thanks for your reply. Actually we have figured that, a datagrid custom control is not behaving consistently for different machines. We found out that the version number of the installed .net framework mscorlib.dll are different as mentioned by Nick, i.e. 1.1.4322.573 and 1.1.4322.2032, which means the revision number is different for these frameworks. Can, you please suggest why it would happen, and as you mentioned how would the assembly version of our code bother thhis behaviour. Also, installing the application from the same msi causes this problem. Thanks, Vinay Kant Show quote "Frans Bouma [C# MVP]" wrote: > Nick wrote: > > > > > We currently have 2 versions of the 1.1 framework being used in our > > project. The problem that comes up is really complex. We have > > certain controls that behave in contrasting fashions if run on > > different machines (having different versions of the f/w). Not only > > that, at times i even end up getting certain build errors like: > > > > Error: The dependency 'Managers, Version=1.0.2130.17591, > > Culture=neutral' in project 'PresentationValidators' cannot be copied > > to the run directory because it would conflict with dependency > > 'Managers, Version=1.0.2125.39306, Culture=neutral'. > > > > Moreover, this problem also creeps up very randomly, so we can't even > > reproduce it if wanted, at will. The versions we currently have are: > > 1.1.4322.573 and 1.1.4322.2032 > > those are the same version, with different file versions. THe assembly > versions are the same, 1.0.5000.0 > > The problem you're running into is with your own code, signed > assemblies. If possible, use a different buildnumber scheme, like > 1.0.0.0, and manually increase that number when necessary and use > assemblyfileversion to crank up the fileversion number with each build. > This way your users can store a single version in the gac, the latest > fileversion, and be happy. > > FB > > -- > ------------------------------------------------------------------------ > Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com > My .NET blog: http://weblogs.asp.net/fbouma > Microsoft MVP (C#) > ------------------------------------------------------------------------ >  |
|||||||||||||||||||||||
Other interesting topics