I'm working on an existing WiX project. The project imports a wix target file.
<Import Project="$(MSBuildExtensionsPath)\MyCompany\MyTargetFile.targets" />
Unfortunately, I cannot seem to find this file anywhere. How was it created in the first place?
As you may know, WiX project files are Visual Studio project files, are MSBuild project files. Target files are MSBuild project files but only contain MSBuild targets that might be used in building projects.
$(MSBuildExtensionsPath) is a common place to put targets files. From the name of your target file and the fact that is it is located under $(MSBuildExtensionsPath), I'd say, you are looking for one that was written by MyCompany and planned to be used by several projects. You might find it on another machine at MyCompany—perhaps on a build server.
Some useful links:
MSBuild
MSBuild Targets
How to: Use the Same Target in Multiple Project Files
Related
I have a class library that has several files that it depends on, and those files must be packaged up for deployment with any project that depends on this library. Right now this means that I must customize each one of those dependent projects to ensure that they copy the files, in addition to adding the library as an MSBuild PrjectReference. When more files are added, all of the projects must be updated.
I've been looking through Microsoft.Common.targets for a way to include these files with the outputs of the library's own project file, so any project that has a ProjectReference to the library will automatically get the files when doing a build. I haven't gotten anything working yet, but I'm curious more generally if this is possible. It seems like it should be, and the _CopyFilesMarkedCopyLocal target even respects an otherwise-unused %(DestinationSubDirectory) metadata item that would allow for customized placement of those files, which would be perfect.
I believe what I'm missing is, for building a project A that depends on project B, the piece that adds the project outputs of project B into the items for project A's build.
EDIT: Leo's comment, I hadn't noticed that files marked with CopyToOutputDirectory are also copied to dependent project output directories because we use ItemGroups with names other than Content, EmbeddedResource, None, etc. Digging deeper, the target that uses those is GetCopyToOutputDirectoryItems and it appears to recursively call the MSBuild task to determine the project outputs, so I should be able to define some custom target that can be imported into our projects that adds our custom ItemGroups in the GetCopyToOutputDirectoryItems target, so that we don't have to use Content/None, etc.
However, the target that does the copying though is _CopyOutOfDateSourceItemsToOutputDirectoryAlways, which doesn't respect %(DestinationSubDirectory) unfortunately, and so all of these files are copied directly to $(OutDir).
My new goal is to see if there's some way to add custom files into the ReferenceCopyLocalPaths ItemGroup of dependent projects so that they are copied instead by the _CopyFilesMarkedCopyLocal target, which does utilize %(DestinationSubDirectory).
Adds custom build action for ItemGroups in the _CopyOutOfDateSourceItemsToOutputDirectoryAlways target
The above title should be closer to bwerks's goal. As test we could to know that the custom build action for ItemGroups would not copied to the Output directory, so we need to our custom build action to the target _CopyOutOfDateSourceItemsToOutputDirectoryAlways.
To accomplish this, open the file Microsoft.Common.CurrentVersion.targets in the MSBuild 15.0 folder C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(Make sure you have sufficient permissions and back up it), find the target _CopyOutOfDateSourceItemsToOutputDirectoryAlways:
<Copy
SourceFiles = "#(_SourceItemsToCopyToOutputDirectoryAlways)"
DestinationFiles = "#(_SourceItemsToCopyToOutputDirectoryAlways->'$(OutDir)%(TargetPath)')"
...
>
<Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>
</Copy>
Then we could to know the copy source file is #(_SourceItemsToCopyToOutputDirectoryAlways), search _SourceItemsToCopyToOutputDirectoryAlways this in the targets, you will find:
<ItemGroup>
<_SourceItemsToCopyToOutputDirectoryAlways KeepMetadata="$(_GCTODIKeepMetadata)" Include="#(ContentWithTargetPath->'%(FullPath)')" Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
<_SourceItemsToCopyToOutputDirectory KeepMetadata="$(_GCTODIKeepMetadata)" Include="#(ContentWithTargetPath->'%(FullPath)')" Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
</ItemGroup>
Could to know the source file is #(ContentWithTargetPath), keeping search the ContentWithTargetPath in the target, finally we got following:
<AssignTargetPath Files="#(Content)" RootFolder="$(MSBuildProjectDirectory)">
<Output TaskParameter="AssignedFiles" ItemName="ContentWithTargetPath" />
</AssignTargetPath>
So, we could to know how the target is to copy the default build action file to the output directory.
Now, go to our custom build action, we just need add our custom build action to the ItemName="ContentWithTargetPath", so add following in the file Microsoft.Common.CurrentVersion.targets:
<AssignTargetPath Files="#(MyBuildAction)" RootFolder="$(MSBuildProjectDirectory)">
<Output TaskParameter="AssignedFiles" ItemName="ContentWithTargetPath" />
</AssignTargetPath>
Save it.
For the file in the project file .csproj:
<ItemGroup>
<MyBuildAction Include="TextFile1.txt">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</MyBuildAction>
</ItemGroup>
Hope this helps.
After using TeamCity, my build process is Visual Studio (sln) -> NuGet Pack. Everything builds fine and the artifact is created. But the artifact has every single file, include the .vbproj, .vb files, the classes folder which only holds .vb files.
Is there a way to turn a setting on to create the artifact which doesn't have all the .vb files etc due to them being compiled in the .dll?
For anyone wondering, I just excluded the .vb files in the nuspec
Have you considered using Octopack to package the nuget. It is smart enough to include all the required files into the package and will not require a custom nuspec file that you would need to source control and manage for any future changes.
IMO custom nuspec file should be used only if you have a very specific requirement such as if the target directory is different.
(mark as content and copy always for the files that you want to include)
I have a number of different MFC language resource files in an MSBuild system, and I'm trying to build different dlls from each. I have a project file for each in the same directory.
What I'd like to do is specify in the main project file the other project files of the resources to be built.
If I use the
<Import Project="lang_de-DE.xml"/>
construction, the main dll will contain the code from the imported projects (according to MSDN MSBuild documentation).
I don't want to use the
<CreateItem Include=.../>
construction either, I have them all in one directory.
I have lang_main.xml, lang_en-GB.xml, lang_fi-FI.xml, etc. in on directory, and the .rc files for these in a different directory.
What I need to do is have the lang_main.xml project file build the others first, and then build itself, and have the same number of dlls in the end.
Is it possible to solve this?
Thanks
Solved.
What I did was create directories for all languages on the same level with the main language, and put a project file for each of them into the corresponding directory.
Then, I put all the resource files into the main language directory, and in the separate project files I reference their own rc file, by relative path.
Then I used the other language "modules" as dependencies in the main language module, in its project file.
I have been searching around for an answer to this question, but I cannot find the documentation on it. I found a few similar questions asked here, but none that completely cover it?
Similar Question
What do all of the different files in the project directory do? I am trying to make my project open source and I don't want to have a ton of unnecessary files in my repository. What files are vital and what files will be generated when the user initially loads the project? Its important to note that this is a VB Form Application
Base Directory:
*.vb
*.Designer.vb
*.resx
*.vbproj
*.sln
*.vbproj.user
*.config
Any of the other folders in the base directory?
*/bin
*/Collection
*/My Project
*/obj
*/Resources
*.suo and *.user files can be ignored. They store user specific settings such as window arrangements, open files etc. Those files are generated by Visual Studio whenever a solution is opened.
*.vb files are somewhat important since they contain your source code...
*.sln and *.vbproj files tell Visual Studio which projects are in a solution and which files are in a project, respectively. They also contain project specific settings such as build plattforms, custom build events, target .NET Framework etc.
*.resx and app.config can be important, depending on your project. They should not be left out when you publish your project, however since they're part of the Visual Studio project. If they're truly not needed you can remove them from the project.
Edit
Folders bin and obj are where Visual Studio generates the compiled output so you should not include those when you publish the source code of your project. Any other folders are project specific so it depends on your project if they're needed or not.
As a rule of thumb, anything that is automatically generated should be excluded when you publish your source code.
Also, if you don't already, you should use a version control system such as Subversion or GIT to manage your sources. Any essential files / folders as explained above should go in there.
I need to collect into a single folder all test assemblies, with their dependencies, and configuration files. The process should preserve the directory structure from the output of each test project. We have a solution that requires manually attaching test projects to a master project, but our solution has far too many projects for this to be maintainable. These should be located automatically based on naming convention (x.UnitTest.csproj, y.IntegrationTest.csproj).
For background, we are working with a build system that passes artifacts (binaries, etc) between agents. We are compiling on one agent, and testing on other agents. The massive duplication of assemblies between test projects is slowing the build process down.
What I have done:
1) I have a csproj that references most of the test projects. This gets binaries and dependencies into one folder.
2) I am able to identify all files to copy using this
<CreateItem
Include="%(ProjectReference.RootDir)%(ProjectReference.Directory)$(OutDir)*.config">
<Output TaskParameter="Include" ItemName="TestConfigurationFiles"/>
</CreateItem>
<Copy
SourceFiles="#(TestConfigurationFiles)"
DestinationFolder="$(OutDir)">
</Copy>
I've attempted most obvious things, such as
MsBuild task: RebaseOutputs attribute, overriding the OutDir property. I can provide the msbuild task with a dynamically generated set of outputs, but can only build them in their default folder.
Hooking into the TargetOutputs of
msbuild task gives only the primary
output assembly (without
dependencies).
I experimented with "Copy Always" for
configuration files. This puts them
in the output directory of the
dependent project as "app.config" not
"dllname.config", and not in the
final project.
Solutions that could make this better might include
Provide an example of adding to the projectreference item array dynamically, before compilation.
Use msbuild TargetOutputs to create a list of all files in the folder (instead of just the primary output) and copy to a destination folder.
Today I'm using msbuild 3.5. Ideally the solution would work with msbuild 3.5. We are transitioning to .NET 4 / MsBuild 4 soon, so, if must be done in .Net 4, that is fine.
Have you considered flattening the folder structure when you export your artifacts?
Something like:
src/*.UnitTest*/bin/**/*.* -> /testlibs
src/*.IntegrationTest*/bin/**/*.* -> /testlibs