I have the following project setup:
Unity project in C:\XXX
Added an another project to solution, located in C:\XXX\Tests
Now, whenever adding a class to that Test project, I found that a .meta file is being added as well.
This doesn't seem correct as .meta files are supposedly only for files inside Assets.
Using Process Monitor I discovered that indeed it is devenv.exe that is creating these .meta files.
Quick-fix:
Using ignores Visual Studio and Unity ignores, these .meta files are not committed to the repository,
And adding this to the csproj will hide them:
<ItemGroup>
<None Update="**/*.meta" Visible="false" />
</ItemGroup>
But in reality, this only hides the problem ...
And unfortunately, this approach won't work in Directory.Build.props, forcing one to manually add former code block to each of these 'external' projects.
Question:
Why are .meta files also created outside Assets and how to turn that off?
For now, putting this in Directory.Build.props at root effectively removes the need to manually update each project:
<Project>
<PropertyGroup>
<DefaultItemExcludes>$(DefaultItemExcludes);**\*.meta</DefaultItemExcludes>
</PropertyGroup>
</Project>
But this only hides the problem instead of fixing it...
Update
The problem comes from Resharper and has been fixed:
Avoid creating meta files outside Assets and Packages (#1489)
Related
I have created a ResourceDictionary file that comes with a .cs file. So afer creating the ResourceDictionary file I'm getting an error The name 'InitializeComponent' does not exist in the current context.
Below is the xaml file associated with the above file.
I'm using VS2022 17.5.0 Preview 1.0
I have set the build action for the c# file to C# Compiler
I have cleaned and rebuilt my project several times and tried deleting the bin and obj folders nothing seems to work
When I do Project / rt-click / Add / NewItem / .Net Maui ResourceDictionary (XAML), this is what gets added to .csproj:
<MauiXaml Update="Dictionary1.xaml">
<Generator>MSBuild:Compile</Generator>
</MauiXaml>
Note that the Compile is nested within the MauiXaml element; it is not a separate Item.
See if your .csproj has TWO separate Items, one for Dictionary1.xaml, another for Dictionary1.xaml.cs.
If so, replace those two items, with a combined item as shown above.
(For me, this builds without problem.)
In your case, the .csproj doesn't show MauiXaml BuildAction?
Replace:
<ItemGroup>
<None Include="Themes\Light.xaml" />
</ItemGroup>
with:
<ItemGroup>
<MauiXaml Update="Themes\Light.xaml">
<Generator>MSBuild:Compile</Generator>
</MauiXaml>
</ItemGroup>
I don't know whether this should be kept or removed:
<ItemGroup>
<Folder Include="Themes\" />
</ItemGroup>
Leave it in for now.
This sounds like a similar issue that often plagues Xamarin solutions. I think that there's an underlying bug, or delay in interpreting the files when displayed within Visual Studio.
Several options:
Make a small change to the file in question - even adding or deleting a space will do, save it and rebuild solution.
Clean the solution and rebuild.
Unload and reload project to which the files belong. (Right click on the project in Solution explorer window, select unload, then select load.
Xaml files may need to be set as embedded resource as their Build Action under their properties (again in Solution explorer).
Summary
I am experiencing a crash in my app which I believe is ultimately caused by having two .csproj files in the same folder. I suspect this may be causing problems since the files in the obj folder do not specify which .csproj they belong to. Is it possible to have two csproj files in the same folder if they both use NuGet references? The files in the obj/ folder seem to suggest that is not a good idea.
Details
I would like to using a library (Common.Standard.csproj) on two separate projects. For reasons which would take a long time to explain, one project needs to reference an older set of nuget packages, while the other project needs newer. To solve this, I created a copy of Common.Standard.csproj which I called Common.MobileStandard.csproj. Both .csproj files are identical except that one references a different set of nuget packages.
My application crashes when I run it, and I have a missing method exception, which I believe is caused by it using the wrong .dll. I've noticed a few other symptoms which I believe are caused by the same root problem. For example, Visual Studio shows a different set of NuGet packages being referenced in the Solution Explorer vs. compared to the .csproj file:
The files shown in Visual Studio's Solution Explorer match the NuGet package references in the other .csproj which is not referenced:
I believe this may be caused by the files stored in the /obj folder. Notice that the "project" files do not specify which .csproj they belong to, so perhaps a single set of "project" files is created despite there being two .csproj files outside of the obj folder?
Am I correct in assuming that this is causing the confusion in Visual Studio, and also the missing method exception at runtime? If so, does that mean that two .csproj files should never share the same folder?
Update 1
I followed suggestions below to use a different in the Common.MobileStandard.csproj so that each .csproj would have its own obj folder, as shown here:
This did produce an objmobile file as expected:
However, the objmobile folder remains empty wnen I build the Common.MobileStandard project. Furthermore, if I delete the contents of the obj folder (the non-mobile one), the nuget packages in Visual Studio get cleared out. It seems as if Visual Studio is always looking in the obj folder rather than in the objmobile, even though the .csproj tells it to look in the objmobile, as shown in the following animation:
I believe the only solution here is to move the .csproj to a separate folder unless I'm mistaken in this being a Visual Studio (or msbuild) bug.
Update 2
It seems that the issue listed in Update 1 is expected behavior. After changing , the following is shown in the output when building the project:
3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(858,5): warning MSB3539: The value of the property "BaseIntermediateOutputPath" was modified after it was used by MSBuild which can lead to unexpected build results. Tools such as NuGet will write outputs to the path specified by the "MSBuildProjectExtensionsPath" instead. To set this property, you must do so before Microsoft.Common.props is imported, for example by using Directory.Build.props. For more information, please visit https://go.microsoft.com/fwlink/?linkid=869650
To fix this, I can create a new file named Directory.Build.props with the following contents:
<Project>
<PropertyGroup>
<MSBuildProjectExtensionsPath>objmobile</MSBuildProjectExtensionsPath>
</PropertyGroup>
</Project>
This does solve the issue in Update 1 (why nuget is still reading from obj) but it brings up a second question - how can I have a different Directory.Build.props for each .csproj file?
It seems I can set BaseIntermediateOutputPath in the .csproj file if I structure it like this:
<Project>
<PropertyGroup>
<BaseOutputPath>bin-example</BaseOutputPath>
<BaseIntermediateOutputPath>obj-example\</BaseIntermediateOutputPath>
<RestorePackagesPath>packages-example\</RestorePackagesPath>
</PropertyGroup>
<Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk"/>
<!-- stuff VS normally puts in <Project> -->
<Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk"/>
</Project>
That is, I pulled the Sdk attribute out of the Project tag and converted it to imports, so that I could set things before importing Sdk.props.
I did that based on the page here: https://learn.microsoft.com/en-us/visualstudio/msbuild/how-to-use-project-sdk?view=vs-2022
In a test rebuild which makes use of nuget packages, this does not touch the obj folder.
It seems .NET Framework projects are structured differently, and I don't think this approach will work there. Hopefully you don't need more than one Framework project in the same directory.
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!
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++.