VS2017 15.4.1
ASP.NET MVC 5.2.3
T4MVC 4.0.0
AutoT4MVC 1.5.3
Resharper
I have been using T4MVC] for many months in this project without issue. However today each time I change a controller method it is generating two T4MVC files:
instead of updating T4MVC.cs which ultimately means the project wont't compile and I have to delete T4MVC1.cs.
Has anyone seen this behaviour or has some ideas of a fix?
Here's the steps I do to fix it:
Delete T4MVC1.cs file.
Unload your project.
Edit the .csproj file.
Check the following tag:
<Compile Include="T4MVC.cs">
<AutoGen>True</AutoGen>
<DesignTime>True</DesignTime>
<DependentUpon>T4MVC.tt</DependentUpon>
</Compile>
Make sure there's only one of these and it's T4MVC.cs. Remove T4MVC1.cs block if you have it.
Check the following tag:
<None Include="T4MVC.tt">
<Generator>TextTemplatingFileGenerator</Generator>
<LastGenOutput>T4MVC.cs</LastGenOutput>
</None>
Make sure the <LastGenOutput> is T4MVC.cs. If not, edit it to be T4MVC.cs.
Save the .csproj file.
Reload the project.
Rebuild
Make sure to check in that code so won't cause any trouble in the future.
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 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'm trying to understand the behavior of building fake assemblies. I'm able to add Fake Assembly in my unit test project, and it compiles into the FakesAssemblies folder locally.
However, I've been having issues lately where my dll's in FakesAssemblies-folder tries to reference an older version of the "QualityTools.Fakes"-reference. This happened after I've installed Update 5 (went from Update 3) of VS2013.
When cleaning the entire solution, the FakesAssemblies seems to be still there and not recompile.
The obvious workaround for this is to delete everything in the FakesAssemblies-folder whenever I need, but is this how it's meant to work?
You can add custom code to .csproj file (before the closing </Project> tag) to do it automatically:
<Target Name="AfterClean">
<RemoveDir Directories="$(ProjectDir)\FakesAssemblies" ContinueOnError="true" />
</Target>