1

Many auto-generated .Designer files in Visual Studio contain a boiler-plate like the one below.

'------------------------------------------------------------------------------
' <auto-generated>
'     This code was generated by a tool.
'     Runtime Version:4.0.30319.18052
'
'     Changes to this file may cause incorrect behavior and will be lost if
'     the code is regenerated.
' </auto-generated>
'------------------------------------------------------------------------------

By default, we have always checked these designer files into source control. This turns out to be in line with Microsoft's recommendation: "custom tools are run at design-time and not at build-time, and therefore the dependent file needs to be checked into source control". Unfortunately, most SO questions out there ask whether or not these designer files should be checked in or not (for example) and neglect the issue of the continually changing Runtime Version and it's affect on source control.

Dan Brackett touches on the issue in this question only his question is specific to the solution of syncing all developers to the same version. This seems like an intimidating task especially, as pointed out by responders to the referenced question, contractors get involved. Interestingly, Dan also comments that this is no longer an issue in VS 2010. However, it appears to be an issue in VS 2012. Perhaps there is a config value to turn it off?

It's a challenge when multiple developers, each with differing .Net versions, check in these auto-generated files with an updated Runtime Version. This fixes it for them but then the other developers show outdated/changed files.

One option is to allow the files to stay outdated with out checking in changes but this makes it difficult for developers to trust the source control status of a project or file.

Another option is to ignore them with your source control software but these files do change legitimately and ignoring them would risk losing important updates or miss having valid changes checked back in to the repository.

Any other options out there for us?

UPDATE: To clarify further, we do not want to have developers targeting different .Net versions such as 3.5 vs 4.0. Our concern is not in the "4.0.30319" part of the version, it's in the last maintenance segment that changes with auto updates to Windows and Visual Studio.

Community
  • 1
  • 1
Rich C
  • 802
  • 2
  • 13
  • 33
  • This is an uncommon problem. Not that many dev shops around that let their devs just install updates willy-nilly. There's an advantage to having an IT guy that's a nazi. – Hans Passant Feb 07 '14 at 20:40
  • @HansPassant that is a surprise to hear. I have never heard of an IT guy getting involved in the version of .Net installed. I can imagine the buildmaster would have something to say about it. Either way, my concern is not in the "2.0.50727" part of the version, it's in the last maintenance segment that changes with auto updates to Windows and Visual Studio. I'll make an update to the question to clarify this. – Rich C Feb 09 '14 at 04:38
  • Sure, that's the one that changes with security and service release updates. The kind that's distributed through Windows Update. IT staff uses WSUS to push updates to clients. – Hans Passant Feb 09 '14 at 05:04

1 Answers1

0

Like the old joke says, "Don't do that!"

Everyone working on the same code has to be targeting the same .NET version. This is chosen on a per-project basis. It isn't left to chance - you don't get whichever version of .NET your developers happen to be running.

You're not finding any discussion about this because it is a non-problem. Remember that it has been a non-problem since .NET 1.0 - well over a decade ago.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • I absolutely agree that developing against differing .Net versions would be a disaster and that the consequences of not agreeing on the version really do render it a necessity and a "non-problem" as you said. However, can the same be said for the ongoing maintenance releases that repeatedly follow a major release like .Net 4.0? Apologies for any confusion in the question. I've updated it to clarify. – Rich C Feb 09 '14 at 04:56
  • It's just not a problem. Set the target version in the project, and let everyone stick with it. – John Saunders Feb 09 '14 at 21:05
  • Are you suggesting that in addition to locking in the major/minor version of the .Net framework to be used in a project, the 3rd and 4th version digits should be specifically selected per project? Wouldn't doing so conflict with the fact that Visual Studio only allows you to select a major.minor version for the Target Framework (i.e. 3.5, 4.0)? – Rich C Feb 10 '14 at 19:11
  • There should only be exactly one version used for the project. Period. Visual Studio may only allow you to specify major.minor: you have to take control of developer workstations if you're going to operate in an Enterprise environment. If you just don't care what versions are being used, then also don't care about a version number in a comment! – John Saunders Feb 10 '14 at 19:22
  • 1
    Or...the maintenance version is much less significant or is at least expected to change regularly without breaking the functionality of the major/minor version. This perspective would perfectly support the fact that only the major/minor versions are listed in the Target Framework dropdown. It would also support the lack of a 4th version number in IIS application pool settings. In which case, it would be unusual to add the 4th version number in the comments of a bunch of auto-generated files. Especially when it's expected that this number will change repeatedly. – Rich C Feb 10 '14 at 19:42
  • You're over-thinking this. The generators simply put the full version number into the comment. It has been that way since day 1. There's no deep significance to that design decision. In fact, the full version was in the comment even before Visual Studio had the ability to choose Framework versions. – John Saunders Feb 10 '14 at 21:31