This week, we finally agreed on our TFS structure, and I checked in all our BizTalk code. It compiled okay before check-in, but after check-in it was giving the following strange error:

Error Error
Build failed. Assembly builder could not generate final assembly
‘C:SourceJFDevBizTalkWireTransferABC.WireTransfer.Bi
zTalk.ArtifactsobjDevelopment~ABC.WireTransfer.BizTalk.Artifacts.d
ll’. Access to the path
‘C:SourceJFDevBizTalkWireTransferABC.WireTransfer.Bi
zTalk.ArtifactsOrchestrationsProcessWireTransfer.odx.cs’ is denied.

At first, I went off on a red herring. I thought this was related to the “obj’ directory needing to be deleted, or that some other file was accessing it.

Then it dawned on me, the problem was really with the xxx.odx.cs file. Why this file? The compiler generates this file, so it never really needed to be checked-in to TFS in the first place. Since I did a mass-checkin from disk (by doing “Add-Files”), these files ended up in TFS as well. Thus, when they were brought down to a new disk structure, they had the “read-only” attribute set.

So I had two solutions, either check-them-out, or delete them. I went with the concept of deleting them on TFS, then deleting them on disk, then the compile worked.

NOTE: When testing with this on TFS, it’s useful to do a test with two developers. Just because it works on one developers machine, doesn’t 100% guarantee that when the second developer checks it out that it will work.

An example of this point is our “add references”. We reference a common binaries folder to allow for more flexibility of each developer building his own solutions. In other words, we typically don’t do references with the solution, and instead reference the a special folder we created called “binaries”. It’s a little bit of a pain to keep it in sync.

Anyway, when we checked in the disk structure, the .DLLs in the Binaries by default were excluded. I had to go back and check them again manually, without the exclude of the .DLL suffix.

Hope this helps…
Neal Walters
06/22/2010