I'm looking for an elegant solution—if there is one—to the problem of linking to an out-of-project shared assembly attributes file and then pushing that project to TFS for a build.
I'm in the process of converting all of my local solutions and projects to source control (it's been a long time coming) and publishing the shared code as NuGet packages. My new design enforces one solution per package, with each solution containing one main project and one test project. In other words, one working assembly per solution.
Previously, when working from my local machine only, I'd reference several of these 'library' projects in a given solution, so the linked shared file solution worked well, e.g. <Assembly: AssemblyCompany("My Company")>
. Consistency among these attributes is very important, for registry key naming, etc.
But now sending these projects to the build server presents a problem; the linked file doesn't exist on the server and so the build naturally fails.
I'm trying to avoid the tedium and human error that comes with manually editing the AssemblyInfo.vb
file for each and every new project I create. Linking was perfect, but it now no longer works. (The code also needs to run locally during dev, so tuning it up in a build step isn't an option.)
I'm rather new to source control and build architectures; what are good folks out there doing to address this issue?
The solution turned out to be pretty easy.
Here's how:
ServiceInfo.vb
copy /y $(SolutionDir)..\ServiceInfo.vb $(SolutionDir)ServiceInfo.vb
$(SolutionDir)ServiceInfo.vb
Depending on your code, the build in Step #3 may fail because it can't find ServiceInfo.vb
. No problem, just build it again after you've created the link in Step #4.
This will ensure that ServiceInfo.vb
is included in your Git publish to TFS and that your build step on the server will succeed.