Get files hidden in msbuild from Visual Studio? - visual-studio

A file can be hidden from Visual Studio using the "Visible" metadata, e.g.
<Compile Include="Hidden.cs">
<Visible>false</Visible>
</Compile>
The file is still built as part of the project, but isn't displayed in Visual Studio - it's not included in the hierarchy information.
Is it possible to get at this file programmatically, in Visual Studio? E.g. by getting access to the msbuild object model and getting all Items with the Visible metadata set?

The following target lists hidden files:
<Target Name="ShowHiddenFiles">
<Message Text="'%(Compile.FullPath)'" Condition="%(Compile.Visible) == false" />
</Target>

I don't know if there's a better way to get the msbuild object model from a VS project, but I can get all of the currently loaded projects from an msbuild static property:
Microsoft.Build.Evaluation.ProjectCollection.GlobalProjectCollection
And then I can call GetLoadedProjects(path) passing in the path of the project I'm trying to get. From there I can interrogate the returned Project object to get at the items.

Related

Where is Visual Studio Build Action stored?

I'm writing a parser to pull data from various programs.
Some of the programs have "Build Action" set to "None" and I want to skip them.
I was guessing that this property would be in the .csproj, .btproj file, but I don't see it there. So my question is where is it stored?
I'm specifically dealing with BizTalk orchestrations, but I think the same concept would apply to C# and C# project files as well. I'm using Visual Studio 2015 to be compatible with BizTalk 2016.
It seems to create a "None" XML element in the .btproj file as shown below.
I was expecting to be an attribute or element value, not an xml element itself.
<ItemGroup>
<None Include="Orchestrations\PublishPIHistoricalData_v2.odx">
<SubType>Task</SubType>
<TypeName>PublishPIHistoricalData_v2</TypeName>
<Namespace>ABC.Integration.BizTalk.ProcessDataHistorian.Orchestrations</Namespace>
</None>
whereas a compiled orchestration will look like this:
<ItemGroup>
<XLang Include="Orchestrations\PublishPIDataODS.odx">
<SubType>Task</SubType>
<TypeName>PublishPIData_ODS</TypeName>
<Namespace>ABC.Integration.BizTalk.ProcessDataHistorian.Orchestrations</Namespace>
</XLang>

How to apply nested files in Visual Studio 2019 for Class Library project

Microsoft Visual Studio Community 2019.
Version 16.9.5.
I want *.Generated.cs files to be nested under corresponding *.cs file in a Class Library project exactly like in does in a RestApi Console Application project.
File nesting is enabled for both projects, Active Settings is set to 'Web' for both.
Using Visual Studio 2019 (16.10.3) here. Based on the recommendation of another answer I got it to work by putting the following in the .csproj file, then reopening the solution. I don't know if it matters or not, but I put this as the last elements group the closing </Project> tag in the file.
<ItemGroup>
<ProjectCapability Include="DynamicDependentFile" />
<ProjectCapability Include="DynamicFileNesting" />
</ItemGroup>

How can I get VS to consider my project dirty when (only) an .exe Content item is dirty?

My C++ project includes a set of (non-code) files that need to be copied to the output directory verbatim. I added them to my .vcxproj as Content nodes with CopyToOutputDirectory set to PreserveNewest. For example:
<ItemGroup>
<Content Include="util.exe">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
<Content Include="lib_util_needs.dll">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
<!-- etc. -->
</ItemGroup>
This almost works; when I build the project, each content file is correctly copied to the output directory if its timestamp is newer than whatever's already there. But... if I update one of these content files without modifying an actual compiled code file at the same time, Visual Studio 2017 concludes that the project is already up to date, does not build, and does not copy the newer version of the content file to the output directory. Is there anything I can do about this? Things that do not work:
Setting PublishState to Prerequisite under the Content node
Listing content files as DependentUpon nodes under a code file's node
Edit: After further investigation, it appears that the behavior depends on the content file's extension. For example, dlls behave the way I want (project marked as dirty and built if the timestamp is updated), but exes do not.
How can I get VS to consider my project dirty when (only) a Content item is dirty?
You can set the property the UpToDateCheckInput to the item:
<ItemGroup>
<UpToDateCheckInput Include="util.exe">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</UpToDateCheckInput>
<!-- etc. -->
</ItemGroup>
Or set the property DisableFastUpToDateCheck to true in the project file to disable FastUpToDateCheck for Visual Studio build manager:
<PropertyGroup>
<DisableFastUpToDateCheck>True</DisableFastUpToDateCheck>
</PropertyGroup>
Check MSDN about DisableFastUpToDateCheck:
A boolean value that applies to Visual Studio only. The Visual Studio
build manager uses a process called FastUpToDateCheck to determine
whether a project must be rebuilt to be up to date. This process is
faster than using MSBuild to determine this. Setting the
DisableFastUpToDateCheck property to true lets you bypass the Visual
Studio build manager and force it to use MSBuild to determine whether
the project is up to date
Hope this helps.

T4 templates not generating output in new VS2017 csproj projects

I migrated a project.json/.xproj project to the newer CS2017 .csproj format.
The project contains a T4 (.tt) template file.
It doesn't regenerate its output on save or build. The output .cs file isn't nested below the .tt file either.
Is there something I have to do to get this working?
.tt files are only auto-run by VS on save. You can install AutoT4 to have them run before/after build. (Be aware that at the moment there is a limitation with the new .csproj files - the options don't show up for them in the properties window.)
If you've converted from the old project.json/.xproj format, you may need to add the template to the project explicitly:
<ItemGroup>
<None Update="Foo.tt">
<Generator>TextTemplatingFileGenerator</Generator>
<LastGenOutput>Foo.cs</LastGenOutput>
</None>
<Compile Update="Foo.cs">
<DesignTime>True</DesignTime>
<AutoGen>True</AutoGen>
<DependentUpon>Foo.tt</DependentUpon>
</Compile>
</ItemGroup>
Related GitHub issue
Edit
As mentioned in the comments below, you can do this quickly & easily by excluding, then including the template in your project.
I realise this is 2+ years old but for those bumping into this issue years on like me, the method listed below works for me without installing anything. I had the exact same issue, after upgrading a project from Visual Studio 2010 to Visual Studio 2017. YMMV. Make a backup copy of your .csproj file before you start.
Forcing rebuild of all .tt files when you build your project can be achieved without installing anything, by editing the .csproj project file. Editing the .csproj file seems clunky, but is is the approved way https://learn.microsoft.com/en-gb/visualstudio/modeling/code-generation-in-a-build-process?view=vs-2015
Within your .csproj file, you will find lots of PropertyGroup nodes. At the end of the list of PropertyGroup nodes (position not critical), add another PropertyGroup node with this content:
<PropertyGroup>
<TransformOnBuild>true</TransformOnBuild>
<TransformOutOfDateOnly>false</TransformOutOfDateOnly>
</PropertyGroup>
Now look near the end of the .proj file, and you will see a line like this:
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
(For interest, on my computer with VS2017 on it that resolves to C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.CSharp.targets)
Beneath that line, add a line like this:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v15.0\TextTemplating\Microsoft.TextTemplating.targets" />
(For interest, on my computer that resolves to C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\TextTemplating\Microsoft.TextTemplating.targets)
YMMV. If yours is a web project, there is probably a line nearby that is similar but to do with Microsoft.WebApplication.targets, from which you can draw inspiration.
That, possibly with a restart of Visual Studio, should do it. If you delete the transformed file that your .tt file emits, and then do a rebuild of your project, you should see that the emitted file reappears.

Does Visual Studio support adding MSBuild tasks to projects?

I'm trying to add some simple MSBuild tasks to a Visual Studio project (VS 2012 Express) - specifically, to create a subdirectory then copy some files to a subdirectory of the output directory ready for packaging.
I see that VS supports custom build steps, which are command-line invocations. However, since VS is based on MSBuild it should be possible to add these directly as MSBuild tasks like the Copy Task in the AfterBuild pre-defined target.
What I can't find is any way to actually add such tasks within the framework of Visual Studio. The documentation only talks about it from an MSBuild perspective, not how it works within Visual Studio's UI. It also doesn't seem to discuss the properties that refer to build output etc there; presumably they're just those used by msbuild its self.
Is there support for MSBuild task management in Visual Studio's UI and it's just crippled out of my Express edition? Or do I have to go hack the project file XML to add MSBuild tasks? Is that supported and the way it's supposed to be done?
I'm used to working with Eclipse and Ant or Maven, where all this is supported within the IDE, though of course you can hack the XML directly. Finding no UI at all for MSBuild task management in Visual Studio is quite confusing. Am I missing the obvious or crippled by using the freebie edition?
For C++ projects, you can use the property
<CppCleanDependsOn>DeleteOutputs;$(CppCleanDependsOn)</CppCleanDependsOn>
instead of defining the BeforeClean target like you did.
From what I read, CallTarget is to be avoided. In your example, you should use DependsOnTargets to do that, as you see in many dummy targets in the MS supplied files. The analogous mechanism of a function where a target just "calls" other targets is done with DependsOnTargets. The flow is not really the same as procedural programming.
Intellisense: I never use it. Is that true for conditional AdditionalIncludeDirectories in the props file only? Go ahead and edit the entry in the proj file where the IDE put it, if you edit the property in the IDE with just one configuration chosen.
(After a bunch more reading I found out how this works):
Visual Studio doesn't seem to expose advanced MSBuild project editing, even though modern vcxproj files are just MSBuild project files with a bunch of extra labeled properties and other entries for Visual Studio IDE specifics. So you have to hack the project XML.
To make it cleaner, only add one line to your actual vcxproj file - an include of a .targets file that contains the rest of your build customisations. e.g, just before the end of the project file, insert:
<Import Project="pg_sysdatetime.targets" />
</Build>
Now create your .targets file with the same structure as any other MSBuild project. Here's mine from the project I've been working on:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- MSBuild extension targets for Visual Studio build -->
<PropertyGroup>
<DistDir>pg_sysdatetime_pg$(PGMAJORVERSION)-$(Configuration)-$(Platform)</DistDir>
</PropertyGroup>
<ItemGroup>
<DocFiles Include="README.md;LICENSE"/>
<ExtensionSourceFiles Include="pg_sysdatetime--1.0.sql;pg_sysdatetime.control"/>
<ExtensionDll Include="$(TargetDir)\pg_sysdatetime.dll"/>
</ItemGroup>
<Target Name="CopyOutputs">
<Message Text="Copying build product to $(DistDir)" Importance="high" />
<Copy
SourceFiles="#(DocFiles)"
DestinationFolder="$(DistDir)"
/>
<Copy
SourceFiles="#(ExtensionDll)"
DestinationFolder="$(DistDir)\lib"
/>
<Copy
SourceFiles="#(ExtensionSourceFiles)"
DestinationFolder="$(DistDir)\share\extension"
/>
</Target>
<Target Name="DeleteOutputs">
<Message Text="Deleting $(DistDir)" Importance="normal" />
<Delete Files="$(DistDir)"/>
</Target>
<!-- Attach to Visual Studio build hooks -->
<Target Name="BeforeClean">
<CallTarget Targets="DeleteOutputs"/>
</Target>
<Target Name="AfterBuild">
<CallTarget Targets="CopyOutputs"/>
</Target>
</Project>
This can contain whatver MSBuild tasks you want, grouped into targets. It can also have property groups, item groups, and whatever else MSBuild supports.
To integrate into Visual Studio you add specially named targets that invoke what you want. Here you can see I've defined the BeforeClean and AfterBuild targets. You can get the supported targets from the VS integration docs.
Now, when I build or rebuild, a new directory containing the product DLL and a bunch of static files is automatically created, ready to zip up. If I wanted I could add the Nuget package for MSBuild Community Extensions and use the Zip task to bundle the whole thing into a zip file at the end too.
BTW, while you can define properties in your .targets files it's better to define them in property sheets instead. That way they're visible in the UI.
I'm using VS2010 Pro, and it doesn't expose the AfterBuild target, at least in C++ projects which is what I'm doing. As you see, it does have the "Events", which according to what I've read are for backward compatibility with converted projects from VSBuild. I agree, a MSBuild task rather than a command script is the way to go.
Forget the UI. It's made to support free editing of the XML files, and continue using the UI too as it respects what you had in there and uses labels for its own stuff so it can find it to update it.
But to keep it neat, you could use a property page; a stand-alone XML file with *.props name, and put what you want in it. Then add that props file to the projects using the UI. You won't hand-edit the project file that the UI is maintaining, and it won't touch the props file unless you go through the property manager view and open it explicitly.
Oh, I also recall seeing additional standard targets something like Package and Publish. Maybe those are not used on your project type, but you could use those entry points anyway.

Resources