[p4] perforce versus VS2008 auto-generated files

[Steve M. Robbins]

Hi,

I'm struggling with the interaction of Microsoft Visual Studio 2008
and perforce's design of marking checked-out files as read-only.

We have a codebase built using Visual Studio 2008 that contains
resource files (SR.resx). Some tool will create a file named
"SR.Designer.cs" from SR.resx and VS2008 adds it to source control.
All is well when first created. Things go badly when a second
developer checks out the sources on his machine.

We use Perforce, which checks out files read-only.

If the second developer is starting from scratch, the first build
generally fails with the message "Cannot write to the Strongly Typed
Resource class file "SR.Designer.cs". We need to set all the files to
read-write in order to do the build. This despite the fact that the
SR.Designer.cs files are not changed (checked via "diff" after the
build).

This also plays havoc with our build server, where we'd like to do the
build starting from an empty directory, pull the sources and build.

How do folks deal with this situation?

The generated code contains:

/// <summary>
/// A strongly-typed resource class, for looking up localized strings, etc.
/// </summary>
// This class was auto-generated by the StronglyTypedResourceBuilder
// class via a tool like ResGen or Visual Studio.
// To add or remove a member, edit your .ResX file then rerun ResGen
// with the /str option, or rebuild your VS project.

Can I configure StronglyTypedResourceBuilder in any way?

Thanks,
-Steve

P.S. Feel free to answer on StackOverflow [1] where I have also posed this question.

[1] http://stackoverflow.com/questions/2283777/vs2008-auto-generated-files-versus-source-control-read-only-checkout-best-practi

[Matt Janulewicz]

Wrestling with any source control (scc) connection to Visual Studio is
no picnic. The main problem is that there is a certain, ancient
VisualStudio-centric API that everyone else has to wedge themselves into.

In any case, I would first look at what your build process is doing with
these files, as even though they don't change something is obviously
thinking that maybe they *want* to change them. Perhaps a build process
wants to touch them to change the date stamp. The easiest/best/cleanest
thing to do is to change the build process so these files are not
touched during a build. I'm guessing that subsequent builds after the
first one are attempting to re-generate these files. So why check them
in in the first place?

If, perhaps, these files are intended to be changed then you'll have to
ask yourself why and how, and if you intend to check them in afterward,
when the second person does a build. Or if you are doing a clean build.

If you intend to change the files then the build process must check them
out.

You can also dd the '+w' attribute to these files so they are always
writable when synced to a workspace. Then set up a typemap for these
files so when they're newly added they take on the +w attribute
automatically.

Since the below comment mentions that to add a class you have to edit
the resx file and re-generate the .cs file, I'd strongly lean toward not
checking in these generated files.

You might also be tempted to switch your workspaces to 'all write' mode.
I'd strongly discourage developers from doing this. As you allude to
the read-only-ness of a file is germain to the VS plugin working
properly. This feature is nice for automated build servers and the like
but for day-to-day work it can really mess things up.


-Matt Janulewicz
Lucasfilm Entertainment Company Ltd.

Post by Steve M. Robbins
Hi,
I'm struggling with the interaction of Microsoft Visual Studio 2008
and perforce's design of marking checked-out files as read-only.
We have a codebase built using Visual Studio 2008 that contains
resource files (SR.resx). Some tool will create a file named
"SR.Designer.cs" from SR.resx and VS2008 adds it to source control.
All is well when first created. Things go badly when a second
developer checks out the sources on his machine.
We use Perforce, which checks out files read-only.
If the second developer is starting from scratch, the first build
generally fails with the message "Cannot write to the Strongly Typed
Resource class file "SR.Designer.cs". We need to set all the files to
read-write in order to do the build. This despite the fact that the
SR.Designer.cs files are not changed (checked via "diff" after the
build).
This also plays havoc with our build server, where we'd like to do the
build starting from an empty directory, pull the sources and build.
How do folks deal with this situation?
///<summary>
/// A strongly-typed resource class, for looking up localized strings, etc.
///</summary>
// This class was auto-generated by the StronglyTypedResourceBuilder
// class via a tool like ResGen or Visual Studio.
// To add or remove a member, edit your .ResX file then rerun ResGen
// with the /str option, or rebuild your VS project.
Can I configure StronglyTypedResourceBuilder in any way?
Thanks,
-Steve
P.S. Feel free to answer on StackOverflow [1] where I have also posed this question.
[1] http://stackoverflow.com/questions/2283777/vs2008-auto-generated-files-versus-source-control-read-only-checkout-best-practi

[Steve M. Robbins]

Thanks, Matt,

You provide a lot of good, general advice.

Post by Matt Janulewicz
In any case, I would first look at what your build process is doing
with these files, as even though they don't change something is
obviously thinking that maybe they *want* to change them. Perhaps a
build process wants to touch them to change the date stamp. The
easiest/best/cleanest thing to do is to change the build process so
these files are not touched during a build.

Absolutely. My problem is that I haven't yet found any information
on how Visual Studio is using StronglyTypedResourceBuilder. I'm hoping
someone can point me in the right direction.

Post by Matt Janulewicz
I'm guessing that
subsequent builds after the first one are attempting to re-generate
these files. So why check them in in the first place?

This was my first thought and I initially removed all the build files.
Then I learned, sadly, that the build process (such as it is) doesn't
always generate the .cs file if it is missing.

Post by Matt Janulewicz
You can also dd the '+w' attribute to these files so they are always
writable when synced to a workspace.

This is what I've ended up doing.

Thanks,
-Steve