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)
Related
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)
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 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.
In my .net core application, I would like to have my partial files put under a given file like it was with a .net framework application using the tag DependentUpon in the csproj.
As shown in a picture, I would like all Program.*.cs files to be under Program.cs.
However, in the .csproj file, I do not see the file listed:
Is there a way to do that in a .net core app?
Yes, you just put an entry in an ItemGroup to update the implicit Compile elements from globbing. I'd personally use a separate ItemGroup element for this, away from your dependencies:
<ItemGroup>
<Compile Update="Program.*.cs">
<DependentUpon>Program.cs</DependentUpon>
</Compile>
</ItemGroup>
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>