I've got a simple project which contains resources (localization/globaliztion).
The part of *.csproj file looks like this:
<ItemGroup>
<EmbeddedResource Update="Resources\ErrorMessages.resx">
<Generator>PublicResXFileCodeGenerator</Generator>
<LastGenOutput>ErrorMessages.Designer.cs</LastGenOutput>
</EmbeddedResource>
</ItemGroup>
<ItemGroup>
<Compile Update="Resources\ErrorMessages.Designer.cs">
<DesignTime>True</DesignTime>
<AutoGen>True</AutoGen>
<DependentUpon>ErrorMessages.resx</DependentUpon>
</Compile>
</ItemGroup>
So, as far as I understand ErrorMessages.Designer.cs file should always be compiled, but when I try to delete it and build the project this file is never compiled (created) and build fails.
I assumed that I could freely add those files to .gitignore but as far as I understand my thought process was incorrect, wasn't it?
The designer files are (re)created, when the file that they represent as C# code does change (is saved/updated, etc.). In this case, the file is only regenerated when the ErrorMessages.resx file is saved/changed/updated. This doesn't happen during a build, but only when the user actively does that. You need to keep the designer files (also in source control) or your build will fail - as you have discovered.
(Note this is not to be confused with Roslyn Source Generators, where the generated files are (generally) not to be kept or checked into source control)
Related
When i try to embed resources in a .NET Core Webservice project via EmbeddedResource in the .csproj file, these resources are also copied into the output folder, although i choose the option to NOT copy in the build action dropdown-menu.
The part where the resource is embedded looks like this:
<ItemGroup>
<EmbeddedResource Include="Resources\logging.json" />
</ItemGroup>
In another .NET Core project, which is a library, the resource gets embedded and won't be copied to the output directory.
There, the snippet looks like this:
<ItemGroup>
<EmbeddedResource Include="LicenseText\*.txt" />
</ItemGroup>
Is there an explanation to this behaviour?
I can reproduce your issue on my side. I checked the official document about EmbeddedResource item, and the metadata introduced like this
CopyToOutputDirectory Optional string. Determines whether to copy the file to the output directory. Values are: 1. Never. 2. Always. 3. PreserveNewest.
I tested by adding related metadata into .csproj file manually, but the issue remained.
<ItemGroup>
<EmbeddedResource Include="Resources\logging.json">
<CopyToOutputDirectory>Never</CopyToOutputDirectory>
</EmbeddedResource>
</ItemGroup>
I think this should be a potential issue and I have reported it to Microsoft Developer Community, hope VS product team can fix it and share the insights. Here is the link: Embedded Resources still copy to output directory even set CopyToOutputDirectory to Never.
I have multiple config files for the different environments for my C# application. They appear as subitems under App.config. The problem is I want to add a new option, in this case JMTelcom, but it appears outside the folder structure. The file seems to be working fine at compile time, but how do I make it appear next to its siblings?
<ItemGroup>
<Compile Update="App.*.config">
<DependentUpon>App.config</DependentUpon>
</Compile>
</ItemGroup>
Add/append above lines to your .csproj file should do the trick. (Assuming your project is using .net core)
I have a number of C# files I am generating. I would like them to automatically be nested under the matching C# file inside the Visual Studio solution explorer. For example, Foo.Generated.cs and Bar.Generated.cs would be nested under Foo.cs and Bar.cs, respectively.
If possible I'd like to be able to manage this in my Directory.Build.props file, so all the class libraries in my solution will have the same behavior.
Versions
.NET Core 3.1
Visual Studio 2019 (16.5.3)
Failed Attempt A:
<Compile Update="**\*Generated.cs">
<DependentUpon>$([System.String]::Copy(%(Filename)).Replace('.Generated', '.cs'))</DependentUpon>
</Compile>
Failed Attempt B:
<Compile Update="**\*Generated.cs">
<DependentUpon>%(Filename)</DependentUpon>
</Compile>
Failed Attempt C:
<Compile Update="**\*Generated.cs">
<DependentUpon>%(Filename).cs</DependentUpon>
</Compile>
The above approaches have also been tried with:
<ItemGroup>
<ProjectCapability Include="DynamicDependentFile" />
<ProjectCapability Include="DynamicFileNesting" />
</ItemGroup>
If possible I'd like to be able to manage this in my
Directory.Build.props file, so all the class libraries in my solution
will have the same behavior.
First, I think you should use Directory.Build.targets rather than Directory.Build.props. As this document shows, Directory.Build.props is imported very early in Microsoft.Common.props and Itemgroup elements are recognized after MSBuild Properties, so when you add items in Directory.Build.props, these elements will not be recognized by MSBuild.
However, Directory.Build.targets is imported very late which MSBuild already starts to recognize them at that time and with it, you can add any items that can be recognized in that file.
Solution
1) change your file to Directory.Build.targets
2) add these(yours) in it:
<Compile Update="**\*Generated.cs">
<DependentUpon>$([System.String]::Copy(%(Filename)).Replace('.Generated', '.cs'))</DependentUpon>
</Compile>
And it works in my side and hope it could help you.
i have a new visual studio solution that has around 350 projects. it takes visual studio a lot of time to compile the .sln file so i implemented Directory.Build.props to avoid copying of references that are not needed to copy to the local directory so the build can be made quicker. below is the code that im using inside the Directory.Build.props file under the root folder.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemDefinitionGroup>
<Reference>
<Private>False</Private>
</Reference>
<ProjectReference>
<Private>False</Private>
</ProjectReference>
</ItemDefinitionGroup>
</Project>
since i placed Directory.Build.props under root folder it is being applied for all projects.
Question::
how can i exclude few projects from applying Directory.Build.props so that the references can be copied to the local.
in short i want the Directory.Build.props to be applied to only 300 projects under the solution file remaining 50 projects need to be excluded from this
how/where can i write a condition in the above code that will exclude certain projects being affected by this code
For others dealing with the same problem, there is another trick that can be used to exclude certain project from using the Directory.Build.props file found at root level.
If you add a dummy Directory.Build.props file in the project you want to exclude, then the Directory.Build.props from the root will not be used. This is because MSBuild walks the directory structure upwards from the location of your project, until it locates the first Directory.Build.props. That will be used. This behavior is documented on the Customize your build page under Search scope at the Microsoft docs.
Sample of the dummy Directory.Build.props:
<Project>
<!-- Only here so that the default Directory.Build.props will not be used. -->
</Project>
I found this to be a convenient way to solve this issue. Especially when dealing with only a few projects that need to be excluded.
I had to work around this in a bit of a hacky way.
In my example, there was a custom analyzer project I wrote that I did not want included in another set of projects. I ended up writing something like this in my Directory.Build.props:
<Project>
...
<Choose>
<When Condition="$(MSBuildProjectName)!='Analyzer' AND ...">
<ItemGroup>
<ProjectReference Include="..\Analyzer\Analyzer.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<OutputItemType>Analyzer</OutputItemType>
</ProjectReference>
</ItemGroup>
</When>
<Otherwise>
...
</Otherwise>
</Choose>
...
</Project>
Where I filled in ... with the projects I wanted it to skip.
I understand this may not be the exact answer you were looking for, but I did a ton of research and was also unable to find any way to do it the way you described. The stuff I have posted was the only way I was able to achieve the ability to exclude certain things from being applied to specific projects by filtering via name. I know that this is hacky and sucks, but it's the only thing that was able to work for me.
Also note that <Otherwise></Otherwise> may be turned into <Otherwise /> possibly, and may even be optional altogether. I left it there so that you could place stuff inside of it if needed.
I'm doing some interop with unmanaged .dlls in a standard c# project. I cannot add these .dlls as simple references and have to use P/Invoke to actually use them. They don't include manifests so doing any clever reflection stuff to load these dynamically (And thus solve the problem of including them as explicit, separate files) is simply out of the question.
I am not concerned with installer releases, I can tell WiX(Or whatever installer platform I choose) what files to exactly put where on a target system.
The problem is in terms of debugging output, I need these .DLLs side-by-side with my own project's executable, but I don't want them cluttering up my actual managed code.
So my situation is this;
I add several .dll's into a project's folder as links.
I attempt to change the .csproj to output the linked files at the root of the debugging output.
It looks something like this:
<None Include="..\..\externals\MyLibraries\ADll.dll">
<Link>TidyFolder\ADll.dll</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
Now, normally you'd change the <Link> tag to where you want the output to go, but doing this:
<None Include="..\..\externals\MyLibraries\ADll.dll">
<Link>ADll.dll</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
Changes the folder the linked .dlls are residing in within my project explorer; it does output correctly, but the clutter is undesirable and the reason why I wanted to throw them into a folder in the first place.
TL;DR: How can you simultaneously control where a linked item is visible within a project, as well as its output location on debug.
Consider adding them as embedded resource:
<ItemGroup>
<EmbeddedResource Include="..\..\externals\MyLibraries\ADll.dll">
<Link>TidyFolder\ADll.dll</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</EmbeddedResource>
</ItemGroup>