Develop Reference

.NET Maui The name 'InitializeComponent' does not exist in the current context

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).

Can two CSPROJ exist in the same folder if they both use nuget files?

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.

Visual studio creates unusual files automatically when Press CTRL + S [duplicate]

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.

Why is Visual Studio creating .meta files even outside Assets folder?

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)

ReSharper - Include external source files in code inspection

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