I have a simple T4 template that writes out a .cs file containing an AssemblyFileVersionAttribute, for the purpose of automatically incrementing the build number.
I have a pre-build event configured to use TextTransform.exe to run the template.
This worked fine in previous versions of Visual Studio, but in Visual Studio 2017 (the preview version, if it matters) I get this error on around 50% of builds:
The process cannot access the file 'C:\MyProj\Properties\BuildIncrement.cs' because it is being used by another process.
The only other process I guess that could be using the file is msbuild, but I would have thought it would wait until after the pre-build events complete before starting compilation.
Any ideas how I can resolve this?
Related
So here's the scenario: I have several wix projects that the exact same extra msbuild targets and tasks to automate some very tedious tasks: things like building a help file and authenticode signing the msi and output files using signtool.exe.
Having gotten tired of copying changes to these scripts into 5 different repositories every time I made a fix. So I got clever and I turned them into nuget packages with a .targets file in the build folder. A simple nuget restore turns a laundry list of packages into targets files.
The problem
Wix v3 doesn't like packages. It doesn't support package references so packages.config looks like the thing. Except that visual studio doesn't like packages.config. It will happily restore the packages (into the folder I specified with a nuget.config) but none of the .targets files are automatically imported.
Easy enough to fix: I just added an import statement into my wixproj file. Except that visual studio doesn't automatically re-evaluate the wixproj after running the restore operation. We can work with this, but it is really annoying to have to build, unload the project, reload the project, and rebuild any time the packages change.
So I tried to fix it
I crawled through the log output of a standard C# project build and discovered the Nuget.Targets file, which can be imported into a project to provide pack and restore targets. It also let me convert to packagereferences, which are somewhat more convenient and less messy than packages.config, but I still had to manually add the import statement for the nuget.g.targets and nuget.g.props files that were produced by the restore target.
And, since I had to manually import those files, I'm right back to the build, unload, reload, rebuild workflow.
Attempt number 2
I discovered through intense internet searching that msbuild recently added a /restore flag to their command line utility specifically to force a project re-evaluation after restoring packages. This works on the command line, but visual studio seems to be clueless. (Maybe because of something that wix v3 does behind the scenes in the Visual Studio template?) In any case, they mentioned in the issue notes that they are essentially using an msbuild task with new global properties to force a re-evaluation. So I attempted to add such a step to the pre-build event of my wixproj, but no sauce.
The question
How do I tell visual studio to re-evaluate this wixproj after running restore? Is there some sort of property or item group I need to add to the wixproj? Is there some kind of target I can insert into the build process?
Update 1:
Found a project property that looked promising: UseHostCompilerIfAvailable, but it didn't work. Still got the same problem.
I'm in the process of updating an old solution from Visual Studio 2005 to Visual Studio 2015, and I'm trying to reproduce as much of our old kludgy behavior as we safely can to minimize the downstream effects. I'm currently running into an issue with the Website Property Pages and MSBuild.
The path here is mostly correct, except that we want the configuration used to be in the path as well. So a Debug build will go into E:\Projects\...\PrecompiledWeb\Debug\MyService and a Release build will go into E:\Projects\...\PrecompiledWeb\Release\MyService. Is this doable? Is there a variable I can insert to make that determination when building?
We're using msbuild against the containing solution file (via TeamCity if it matters, but I can replicate it without it).
Edit: I've found the Debug.AspNetCompiler.TargetPath and Release.AspNetCompiler.TargetPath paths in the solution, but if I change them to be separate, the Debug one overrides the Release one when I next open the dialog.
When MSBuild starts building the project, it takes one or several project files. This dialog takes it parameters from MSBuild project file (you can edit it either from Visual Studio, or simply in every text editor). The project should have the property, called $(Configuration). You can use it in your output variable:
<OutputPath>E:\Projects\...\PrecompiledWeb\$(Configuration)\MyService</OutputPath>
One thing you must aware of is that the property $(Configuration) must be declared before the $(OutputPath) property.
We have an MSBuild task that builds our *.sqlproj file, the output of which is loaded back into TeamCity as an artifact for subsequent deployment.
Similar to this user, we are having some unpredictable output file naming happen:
Invalid file names when trying to deploy SSDT project with TeamCity 8
It appears that sometimes, it produces this output file under /bin/Release:
MyProj.sqlproj.dacpac
Then subsequent builds produce this file in the same folder:
MyProj.dacpac
We haven't done indepth testing yet - I was wondering if anyone else has seen similar or has a suggested troubleshooting path?
To be clear, it's the same task, running the same command against the same project - just run repeatedly overtime as new checkins happen.
Sounds like you have conflicting .sqlproj files being checked in.
I'd start by checking the history.
Well, after looking more closely at the build log I could see that the TeamCity MSBuild runner appears to be creating some temporary virtual project files (or something, I don't know for sure because they get deleted) with names like:
MyProj.sqlproj.teamcity
I theorized that this may be confusing MSBuild or one of the targets related to building dacpacs, so I replaced the TeamCity MSBuild build step with a Command Line build step that calls MSBuild on the original project file itself, and this appeared to solve the problem. It now produces the dacpac with the file I'm expecting.
I don't have time to dig further now, but I could believe that there's some logic in the chain somewhere that is deriving the name for the final *.dacpac from the name of the project file being used. My guess is that it just strips off everything after the last "." and attaches the ".dacpac" suffix.
I don't fully know why it would occasionally create a *.dacpac file with the correct name, but I was at times doing a manual build in the TeamCity agent work folder from the commandline on the build server itself, so this may have just been a file leftover from previous executions.
When using DefaultTemplate from Visual Sturdio 2012 (and TFS 2012 server), the PDB files are included in build directory. I do not want them.
Is there a way not to generate those files during build process?
Or
How can I delete those files?
I found this thread about deletion but seems a bit strange (no delete activity?)
There also is this answer but does not involve XAML template.
Thanks in advance for your help.
PDB files hold debug information on your code and its not advised to disable them, they are valid output hence deployment shouldn't be messing with them.
You can disable their generation in Visual Studio project Properties> Build > Advanced > Debug Info = none.
If you absolutely want them gone then disable them for build specific configuration (relaese etc.)
The build server by default does whatever the Solution (sln) tells it to. That by default is to do a "Debug" build and that created the PDB's. You can tell the Build to do a "Release" build that will not by default create any PDB's...
Figure: Adding a Build Configuration
I would however recommend against it as the PDB's contain information that you need even in production systems. Consider for a moment that you have a DLL in production and the customer is encountering a problem. You get them to create an InteliTrace log so that you can debug it locally (or they let you debug on their environment) and suddenly you are trying to debug without Visual Studio understanding the relationship between the Executable and the Source Code. So no debug...
Since I was unable to find building option to disable PDB file generation, I delete them afterwards.
There is no easy way to delete files. I did:
use a FindMatchingFiles Activity with wildcard *.pdb, which returns
a full path to pdb files
use a Foreach loop
call a DotNet method in the loop for each file with the InvokeMethod Activity,
with target type System.IO.File and method being "Delete"
In the previous version (Visual Studio 2010)
When we build /release, it was not generating PDBs, the PDB files are created when we only build with /debug:full or /debug:pdbonly, we use /debug:pdbonly if we want to generate PDBs for a release build that we do not want to be debuggable.
This is not the case in Visual Studio 2012, I checked it and I found it generated PDBs in both, /debug and /release
There is no documentation for Visuals Studio 2012.
When I right click on the T4 file and Run Custom Tool, I get the errors
Compiling transformation: Metadata file 'IdeaBlade.VisualStudio.DTE.dll' could not be found
Compiling transformation: Metadata file 'IdeaBlade.VisualStudio.OM.CodeGenerator.dll' could not be found
Compiling transformation: Metadata file 'IdeaBlade.EntityModel.Edm.Metadata.dll' could not be found
Thanks.
That error means that Visual Studio was unable to find some of the DLLs necessary to run DevForce's T4 generation. Probably the easiest way to solve this is by running the Dev Force installer. That will place the necessary DLLs in the GAC where Visual Studio will be able to find them.
I believe you can also add References to these specific DLLs on the project that contains your Data Model but I haven't done that because I prefer to have Dev Force installed on any machine that needs to run the T4s.