My company uses a combination of some database tables, a web page front end and an "export" application to handle our string resources in our web sites.
The export application used to work just fine when we used VS2008, but since switching to VS2010 the resources now have a designer.cs file "beneath" them in the solution explorer.
The problem is that the "export" application only generates the .resx files and not the underlying designer.cs files.
So, is there a way to not have those designer.cs files, or alternatively some way to automatically re-generate (or even some command the export application could call to re-generate them)
I had a problem where VS 2010 would not regenerate the Designer.cs files, and couldn't find the solution elsewhere.
I was able to regenerate them though, without going to the command line.
To fix the issue in Visual Studio 2010 I did the following:
Deleted the Designer.cs file
Right clicked on the main resx file
Selected Run Custom Tool
That rebuilt the Designer.cs file.
Hope that might help someone else in the future..
From MSDN we have:
Compiling Resources into Assemblies
When you build your application, Visual Studio invokes the
resgen.exe tool to convert your application resources into an
internal
class called Resources. This class is
contained in the Resources.Designer.cs
file which is nested under the
Resources.resx file in Solution
Explorer. The Resources class
encapsulates all your project
resources into static readonly get
properties as a way of providing
strongly-typed resources at run-time.
When you build through the Visual C#
IDE, all the encapsulated resource
data, including both the resources
that were embedded into the .resx file
and the linked files, is compiled
directly into the application assembly
(the .exe or .dll file). In other
words, the Visual C# IDE always uses
the /resource compiler option. If you
build from the command line, you can
specify the /linkresource compiler
option that will enable you to deploy
resources in a separate file from the
main application assembly. This is an
advanced scenario and is only
necessary in certain rare situations.
If you prefer to automatically generate the *.designer.cs files from *.resx files when building the project, the following approach worked for us and it might work for you as well:
Close your solution
Open as an XML file the project file in which you want to automatically generate the designer files. Note that you need to load it as an XML file. You can't edit these settings through the project property page.
Add a target to the project as follows:
<Target Name="GenerateDesignerFiles">
<Message Text="Deleting old Designer Files..."/>
<Delete Files="#(EmbeddedResource->'%(RootDir)%(Directory)%(Filename).resources')"/>
<Delete Files="#(EmbeddedResource->'%(RootDir)%(Directory)%(Filename).designer.cs')"/>
<Message Text="Generating Designer Files..."/>
<GenerateResource
Sources="#(EmbeddedResource)"
StronglyTypedLanguage="C#"
StronglyTypedClassName="%(Filename)"
StronglyTypedNamespace="#(EmbeddedResource->'%(CustomToolNamespace)')"
StronglyTypedFileName="#(EmbeddedResource->'%(RootDir)%(Directory)%(Filename).designer.cs')"
PublicClass="true"
>
</GenerateResource>
<Message Text="Generating Designer Files complete."/>
</Target>
Locate the target named "BeforeBuild". This target may be commented out (the default).
Modify the "BeforeBuild" target as follows:
<Target Name="BeforeBuild">
<CallTarget Targets="GenerateDesignerFiles"/>
</Target>
This solution is based on all resource files being listed as "EmbeddedResource" within an ItemGroup of the project file, e.g.
<ItemGroup>
<EmbeddedResource Include="Resources\Creditor\Display_Creditor.resx">
<Generator>PublicResXFileCodeGenerator</Generator>
<LastGenOutput>Display_Creditor.Designer.cs</LastGenOutput>
<CustomToolNamespace>Acme.Web.Resources.Creditor</CustomToolNamespace>
</EmbeddedResource>
<EmbeddedResource Include="Resources\InboundEmail\Tooltip_InboundEmailDetails.resx">
<Generator>PublicResXFileCodeGenerator</Generator>
<LastGenOutput>Tooltip_InboundEmailDetails.Designer.cs</LastGenOutput>
<CustomToolNamespace>Acme.Web.Resources.InboundEmail</CustomToolNamespace>
</EmbeddedResource>
<EmbeddedResource Include="Resources\Creditor\Tooltip_CreditorDetails.resx">
<Generator>PublicResXFileCodeGenerator</Generator>
<LastGenOutput>Tooltip_CreditorDetails.Designer.cs</LastGenOutput>
<CustomToolNamespace>Acme.Web.Resources.Creditor</CustomToolNamespace>
</EmbeddedResource>
</ItemGroup>
Disclaimer: This has been tested with Visual Studio 2013 and C# projects. It may or may not work for other projects and/or other versions of Visual Studio.
Try this:
Right click on resx file
Click on properties
Set the properties:
Copy to output Directory : Copy always
Custom tool : PublicResXFileCodeGenerator
Save and build again.
Problem solved.
Following these steps worked for me.
Delete your designer.cs file.
Click on properties
Out put directory - copy always.
Custom tool: PublicResXFileCodeGenerator
Save and build.
Right click on resx and
Click run custom tool.
Related
I am trying to develop a project that generates code. One of the code files it generates is sql code and I am trying to include it in one of the projects of my solution.
Since I didn't find yet a solution to do this programmatically, I tried to modify the .csproj manually:
<ItemGroup>
<Build Include="DIL\*.sql" />
</ItemGroup>
What my code does it generate a Test.Sql and places it into the DIL folder without including it in the project. If I then go modifying the .csproj as shown above and reload the .csproj itself I will find the Test.sql being added.
However there will be no Build Include="DIL*.sql" / anymore in the .csproj, meaning that if I generate another sql file it will not be added automatically to the project. Is there a permanent solution to this by any chance? Thanks in advance!
I want to move one code file under the group of another, related file, like here:
As you see, SingleObjectViewModel.Commands.cs is hidden in SingleObjectViewModel.cs group. It can be useful in some cases.
I've created SingleDocumentViewModel.Commands.cs but simple drag-n-drop in Visual Studio do not work.
How to achieve it?
I found one way of doing this, but it is not user-friendly and needs to edit project file by hands. I'm not sure it will work in other versions of Visual Studio then mine (MS Visual Studio 2013)
First, unload project (right-click on project, Unload Project).
Then edit csproj file (right-click again, Edit *.csproj)
In editor, replace:
<Compile Include="SingleDocumentViewModel.Commands.cs">
with
<Compile Include="SingleDocumentViewModel.Commands.cs">
<DependentUpon>SingleDocumentViewModel.cs</DependentUpon>
</Compile>
Then save edited file and load project again (right-click on it, Reload project).
Now files are grouped:
I had a VB projected and converted it to C# using online conversion tools. Now the problem is xaml and xaml.cs file do not connect to each other, that is they don't recognize their dependencies (Red area in Fig). Actually it should appear like Window1 Files (Green Area in the image.) How can I achieve this.
I am trying my hands on WPF so may be a layman sort of question.
This is simple, try to add in project existing items and select the XAML (not .cs, etc.) files in list of formats. In VS2010 thats helps.
If you cannot get the IDE to do it (Papa John's post), then you can do it by editing the project file.
That information is in the .csproj file (which is an XML file -- you can open it in a text editor, or by right-clicking on it, choosing "unload", and then opening it -- choose reload to load it up as a project again).
Here is the information to look for, you would need to add the "DependentUpon" tag.
<Compile Include="TheFile.xaml.cs">
<DependentUpon>TheFile.xaml</DependentUpon>
</Compile>
Easiest Way!!!
I came across the same. I got the way out. Here is how to get the .xaml.cs nested under the .xaml in Solution Explorer:
In Windows File Explorer (outside of Visual Studio), open the folder where the required files are.
Select both files (.xaml and .xaml.cs) together.
Drag it onto your project name in the Solution Explorer.
Its done! :)
Using a Xamarin PCL Solution:
1) Go to your PCL folder and open your MySolution.csproj file
2) There should be several groups of <ItemGroup> tags. One of them declares <EmbeddedResource> tags and another will contain, <Compile> <DependentUpon></DependentUpon></Compile> groups of tags.
3) For MyPage.xaml and MyPage.xaml.cs files to be linked, you must have a group of xmls that declare your xaml page.
<EmbeddedResource Include="MyPage.xaml">
<Generator>MSBuild:UpdateDesignTimeXaml</Generator>
<LogicalName>MyPage.xaml</LogicalName>
</EmbeddedResource>
<Compile Include="MyPage.xaml.cs">
<DependentUpon>MyPage.xaml</DependentUpon>
</Compile>
Note that if your page is in a folder you should specify that like so:
<Compile Include="Views\MyPage.xaml.cs">
<DependentUpon>MyPage.xaml</DependentUpon>
</Compile>
<EmbeddedResource Include="Views\MyPage.xaml">
<Generator>MSBuild:UpdateDesignTimeXaml</Generator>
<LogicalName>MyPage.xaml</LogicalName>
</EmbeddedResource>
Note that this works with OSX and Windows
Based on Kyle White's comment on the official Xamarin bug report 55591: .xaml files in .NETStandard library appear twice in solution explorer, I found a simple solution to this problem within the linked .NET Standard sample project by Oren Novotny
Within your .csproj file, add the following <ItemGroup>:
<ItemGroup>
<Compile Update="**\*.xaml.cs" DependentUpon="%(Filename)" />
<EmbeddedResource Include="**\*.xaml" SubType="Designer" Generator="MSBuild:UpdateDesignTimeXaml" LogicalName="%(Filename)%(Extension)" />
</ItemGroup>
Afterwards, all xaml files within the project structure will be displayed in the Solution Explorer window automatically - even if you'll ever add new xaml files.
How does this magic work?
The Compile element within the ItemGroup is using wildcards to iterate through all directories, searching for .xaml.cs files and marking them as dependent on the xaml files of the same name. Please note that this works only because the %(Filename) item metadata used for the DependentUpon element contains the left-most file extension, which matches the name of the xaml file by convention.
The EmbeddedResource element will include all xaml files to the project, so that they are visible within the Solution Explorer window while marking them as Designer files, and declaring that the UpdateDesignTimeXaml target defined within the Xamarin.Forms NuGet package should be used to generate code from the markup file.
Using Xamarin Shared Code solution:
1) Go to you project folder after unloading the shared project
2) Find the projitems file and edit that adding the DependentUpon tag as described in other answers above.
3) Save the file
4) Go back to visual studio and you should get a dialog that allows you to reload all or just open the project again.
An even easier and faster solution for Xamarin Forms projects, no need to touch csproj file at all, very quick fix.
Make sure you have Show All Files selected for solution explorer - it may be on by default.
Select all affected files
Right click > Exclude from Project
Select the same files again (should be faded out)
Right Click > Include in Project
They should now all be nested correctly and all the changes necessary to the .csproj file will be done.
You may have an InitializeComponent() does not exist in the current context) error after this.
If that's the case, the simple fix is..
Select all affected items and change Build Action from Page to Embedded Resource
I was able to just restart Visual Studio for Mac 2019 v16.2 and it reconnected my .xaml & .cs files that should've been connected.
If that doesn't work, Hitsa's solution worked for me as well on a separate occasion.
If you get the Nested File VS Extension, you can do this by right clicking similarly named files and choosing to "nest automatically" or you can nest manually.
https://marketplace.visualstudio.com/items?itemName=MadsKristensen.FileNesting
In a Shared Project there is .shproj file instead of a .csproj file and the and items do not exist there.
However I found there is also a .projitems file and adding a section there as described above caused the .xaml and .cs files to be linked
The usual - Close Visual Studio, delete the vs folder in the root folder of your solution and reopen Visual Studio (2019) just worked for me.
For VS 2019, you have only to edit .csproj file and eliminate all references to .xaml.cs file
es:
<ItemGroup>
<Folder Include="Models\" />
<Folder Include="Services\" />
<Folder Include="ViewModels\" />
</ItemGroup>
<ItemGroup>
<EmbeddedResource Update="Views\MyPage.xaml">
<LogicalName>MyPage.xaml</LogicalName>
</EmbeddedResource>
</ItemGroup>
I found the problem was when i reloaded a github project from my menu, instead of the actual project file inside that local downloaded repo. Once I selected the .sln file it worked again!
Background:
We're using a 3rd party tool in our .NET C# solution. This tool has it's own syntax and integrates with Visual Studio. When we use this tool we write its markup within Visual Studio and then when we build the solution the custom tool runs and generates a .cs file based on the markup we have written.
This generated source file contains a version number which is causing problems when we check these in to version control (Endless conflicts). Our understanding is that it's considered best practice not to check in generated source files.
So we excluded the generated .cs files from SVN and then the next issue we ran in to was that the Visual Studio solution referenced these files, so when TeamCity (Our continuous build/integration software) went to build the solution it would fail straight away as it couldn't find these files.
We then removed these from the solution as well as excluding them from SVN, this fixed the original issue, we're no longer checking in generated code and it builds fine in TeamCity (As the files are re-generated with every build).
We now have a new problem - As the generated files are no longer included in the solution, intellisense and code inspection fails as the generated classes cannot be found. The solution builds just fine (As again the code is re-generated during the build).
Question
Is there a way to tell ReSharper to include generated .cs files in its code inspection? These files are external to the solution but they are in the obj directory.
Cheers,
Tyler
We had a similar problem and couldn't come up with a good solution so I wrote a ReSharper extension to include external code:
https://resharper-plugins.jetbrains.com/packages/ReSharper.ExternalCode
As mentioned in my comment, one workaround is to keep the generated files in the solution (but not in source control), while adding a pre-build step to create empty .cs files (if the real generated file isn't present) so that the file is always available during a build.
In my projects, I use the following MSBuild targets to generate empty files by using the Touch task. You may need to make some modifications - in my case, the target files are actually defined within a project not at the solution level; and the build action for the files is set to "None" which is important to understand how these targets work.
<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<!--
Creates empty 'dummy' files for any files that are specified but do not exist.
To be processed, the following must be true:
1. The file is included in an ItemGroup called CanCreateDummy, e.g.
<ItemGroup>
<CanCreateDummy Include="SomeFile.cs" />
</ItemGroup>
If you want to specify a CanCreateDummy file in the .csproj file, you would
modify the above slightly as follows to prevent it appearing twice:
<ItemGroup>
<CanCreateDummy Include="SomeFile.cs">
<Visible>false</Visible>
</CanCreateDummy>
</ItemGroup>
2. The file is included in the ItemGroup called None. This is normally performed
by adding the file to the project in the usual way through Visual Studio, and
then setting the file's Build Action property to None.
-->
<Target
Name="CreateDummyFiles"
AfterTargets="BeforeBuild"
>
<!--
This voodoo creates the intersection of 2 lists - #(CanCreateDummy) and #(None)
(this latter item is defined in the project file). We want to create a filtered
list of all items that are in both these lists, which is called _ProjectDummyFiles.
See http://blogs.msdn.com/b/msbuild/archive/2006/05/30/610494.aspx for how the
Condition voodoo works.
-->
<CreateItem Include="#(CanCreateDummy)" Condition="'%(Identity)' != '' and '#(None)' != ''" >
<Output TaskParameter="Include" ItemName="_ProjectDummyFiles"/>
</CreateItem>
<Message
Text="Creating dummy settings file #(_ProjectDummyFiles)"
Condition=" !Exists('%(_ProjectDummyFiles.FullPath)')"
/>
<Touch
AlwaysCreate="true"
Files="#(_ProjectDummyFiles)"
Condition=" !Exists('%(_ProjectDummyFiles.FullPath)')"
/>
</Target>
</Project>
Hope this helps
Rich
I just finished setting up an out-of-place build system for our existing C++ code using inherited property sheets, a feature that seems to be specific to the Visual C++ product. Building out-of-place requires that many of the project settings be changed, and the inherited property sheets allowed me to change all the necessary settings just by attaching a property sheet to the project. I am migrating our team from C++/MFC for UI to C# and WPF, but I need to provide the same out-of-place build functionality, hopefully with the same convenience. I cannot seem to find a way to do this with C# projects - I first looked to see if I could reference an MsBuild targets file, but could not find a way to do this. I know I could just use MsBuild for the whole thing, but that seems more complicated than necessary. Is there a way I can define a macro for a directory and use it in the output path, for example?
I'm not quite sure what an "out-of-place" build system is, but if you just need the ability to copy the compiled files (or other resources) to other directories you can do so by tying into the MSBuild build targets.
In our projects we move the compiled dlls into lib folders and put the files into the proper locations after a build is complete. To do this we've created a custom build .target file that creates the Target's, Property's, and ItemGroup's that we then use to populate our external output folder.
Our custom targets file looks a bit like this:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProjectName>TheProject</ProjectName>
<ProjectDepthPath>..\..\</ProjectDepthPath>
<ProjectsLibFolder>..\..\lib\</ProjectsLibFolder>
<LibFolder>$(ProjectsLibFolder)$(ProjectName)\$(Configuration)\</LibFolder>
</PropertyGroup>
<Target Name="DeleteLibFiles">
<Delete Files="#(LibFiles-> '$(ProjectDepthPath)$(LibFolder)%(filename)%(extension)')" TreatErrorsAsWarnings="true" />
</Target>
<Target Name="CopyLibFiles">
<Copy SourceFiles="#(LibFiles)" DestinationFolder="$(ProjectDepthPath)$(LibFolder)" SkipUnchangedFiles="True" />
</Target>
<ItemGroup>
<LibFiles Include=" ">
<Visible>false</Visible>
</LibFiles>
</ItemGroup>
</Project>
The .csproj file in Visual Studio then integrates with this custom target file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" ... >
...
<Import Project="..\..\..\..\build\OurBuildTargets.targets" />
<ItemGroup>
<LibFiles Include="$(OutputPath)$(AssemblyName).dll">
<Visible>false</Visible>
</LibFiles>
</ItemGroup>
<Target Name="BeforeClean" DependsOnTargets="DeleteLibFiles" />
<Target Name="AfterBuild" DependsOnTargets="CopyLibFiles" />
</Project>
In a nutshell, this build script first tells MSBuild to load our custom build script, then adds the compiled file to the LibFiles ItemGroup, and lastly ties our custom build targets, DeleteLibFiles and CopyLibFiles, into the build process. We set this up for each project in our solution so only the files that are updated get deleted/copied and each project is responsible for it's own files (dlls, images, etc).
I hope this helps. I apologize if I misunderstood what you mean by out-of-place build system and this is completely useless to you!
Is there a way I can define a macro for a directory and use it in the output path
Have you looked at the pre-build and post-build events of a project?
Actually, pre-build and post-build events seem to be solely a place to add batch-file type commands. This would not help me to set up standard build directories for our projects, unfortunately. And having these events create batch files seems like a very 1980's approach for a modern language like C#, IMO.
After digging some more, and experimenting, I have found that you can add an <Import> directive into your .csproj file. When you do this, the IDE pops up a warning dialog that there is an unsafe entry point in your project - but you can ignore this, and you can make it not appear at all by editing a registry entry, evidently. So this would give me a way to get the variables containing the directory paths I need into the .csproj file.
Now to get the Output Path to refer to it - unfortunately when you add a string like "$(MySpecialPath)/Debug" to the Output Path field, and save the project, the $ and () chars are converted to hex, and your file get's put in a Debug directory under a directory named "$(MySpecialPath)". Arrgghh. If you edit the .csproj file in a text editor, you can set this correctly however, and it seems to work as long as the <Import> tag appears before the <PropertyGroup> containing the Output Path.
So I think the solution for me will be to create a standard OurTeam.targets MsBuild file in a standard location, add an installer for changing the registry so it doesn't flag warnings, and then create custom project templates that <Import> this file, and also set the Output Path to use the properties defined in the OurTeam.targets file. Sadly, this is more work and a less elegant solution than the property sheet inheritance mechanism in C++.