Develop Reference

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.

VS2015: warning MSB3884: Could not find rule set file

After upgrading my WinForms VS2013 project to VS2015, I started seeing the MSB3884 "Could not find rule set file" warning.
A Google search turned up one MSDN article, which a Stack Overflow article points to as well as numerous other sites.
Similar Question: 33020507
MSDN: VS2015 MSB3884 Warning
I have both VS2013 and VS2015 installed.
The project files giving the warnings (and those that do not), do not have these entries.
<CodeAnalysisRuleSetDirectories>
<CodeAnalysisRuleDirectories>
If I delete the other two entries from the project file, then the problem goes away, which is obvious, as there is no rule file set.
<CodeAnalysisIgnoreBuiltInRuleSets>
<CodeAnalysisIgnoreBuiltInRules>
I am trying to build externally using msbuild, however VS2015 tends to show the problem too.
Interestingly enough, if I click on the open button in the project properties Code Analyzer area, I do get the file.
Specifying a different rule set makes no difference. That makes me think that possibly, there is an environment variable setting, not that any come to mind. Code Analyzers is a function of the project file. I can add a directory attribute, but the consensus is to take out paths, the <CodeAnalysisRule*Directories>.
The GUI uses defaults:
'
Here is a typical project file fragment.
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>TRACE;DEBUG</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<CodeAnalysisIgnoreBuiltInRuleSets>true</CodeAnalysisIgnoreBuiltInRuleSets>
<CodeAnalysisIgnoreBuiltInRules>false</CodeAnalysisIgnoreBuiltInRules>
<Prefer32Bit>false</Prefer32Bit>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<CodeAnalysisRuleSet>BasicCorrectnessRules.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x64'">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x64\Debug\</OutputPath>
<DefineConstants>TRACE;DEBUG</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisIgnoreBuiltInRules>false</CodeAnalysisIgnoreBuiltInRules>
</PropertyGroup>
Without getting rid of the Code Analysis lines from the project file, though saving a project file again would just add it back, how can I eliminate/fix the warning?

I've just had the same problem after upgrading from VS2013 to VS2015.
My solution was:
On the project properties go to the Code Analysis section.
Select the Browse option on the list of rule sets.
Browse to the VS2015 rule sets folder. C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets
Pick a rule set. The default used by new projects is: MinimumRecommendedRules.ruleset
Rebuild. Check the warning has gone.

I hit this warning after migrating from VS 2013 to VS 2015 as well. In my case the error was Could not find rule set file "AllRules.ruleset". The fix for me was to change the VisualStudioVersion setting in the .csproj file to be 14.0 so that it looks in the correct rule set folder:
After that and a rebuild, the warning was resolved. Much easier.

I spent some time looking at the different solutions proposed here - they each had good elements but each required some adjustments. I found a clean solution to be:
Locate an existing or create a <PropertyGroup> element in the project file that has NO conditions (e.g configuration or platform) i.e that will apply to all configurations on all platforms. To this element add a <CodeAnalysisRuleSetDirectories> element specifying the relative path to the "Rule Set" directory from the current dev env directory, e.g:
<PropertyGroup>
<CodeAnalysisRuleSetDirectories>$(DevEnvDir)\..\..\Team Tools\Static Analysis Tools\Rule Sets</CodeAnalysisRuleSetDirectories>
</PropertyGroup>

I got rid of this warning by setting <CodeAnalysisIgnoreBuiltInRuleSets>false</CodeAnalysisIgnoreBuiltInRuleSets>

You said your project files giving off the warnings did not contain any <CodeAnalysisRuleSetDirectories> entry.
Mine did not either, and like you I get the file if I click the Open button in the project properties Code Analysis section.
However, searching all project files in the solution turned up two projects which did have <CodeAnalysisRuleSetDirectories> tags, and those tags contained an older version of the Visual Studio reference in the path.
Fixing those paths fixed my problem, and I've just confirmed that the project which was raising the error references a project which referenced the projects which contained the bad <CodeAnalysisRuleSetDirectories> entries.
So search the whole solution and fix all <CodeAnalysisRuleSetDirectories> paths, or try removing them.
In my case
<CodeAnalysisRuleSetDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\\Rule Sets</CodeAnalysisRuleSetDirectories>
became
<CodeAnalysisRuleSetDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\\Rule Sets</CodeAnalysisRuleSetDirectories>
(Jon Shadforth's answer also worked for me, but I didn't like adding the path to more projects - as timB33 commented)

These binary analyzers are now deprecated link.
I am using VS 2019 and my solution was to edit the projects files and remove all lines related to the CodeAnalysis, in all PropertyGroups:
Before:
After:
*To edit the .vbproj or .csproj in Visual Studio you need to unload the project.
-Perform a right-click in solution and then unload the project.
-Perform a right-click again and go to edit 'fileName'
I didn't try but this solution must work in VS 2015, VS 2017 too.

Had this when compiling a solution upgraded from VS2015 to VS2017 but had MSBuild 14 in the path (C:\Program Files (x86)\MSBuild\14.0\Bin). Changed to ensure 15 was in the path (C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin) and all worked.

I had this error on my build server which has Visual Studio Build Tools on it rather than Visual Studio.
The solution for me was to use the installer to enable Static analysis tools in the individual components list.

For people who are not using Visual Studio but for example Rider or a other IDE:
I had an older version of the compiler installed. So the Ruleset-Files did not exist.
The solution for me was to install the curren Visual Studio Build Tools from:
https://visualstudio.microsoft.com/de/downloads/
In my case 'Buildtools für Visual Studio 2022' - here you need to select the C# Options.
After installation the following folder should exist:
C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Team Tools\Static Analysis Tools\Rule Sets
There the AllRules.ruleset and MinimumRecommendedRules.ruleset is located and should be used if you use the C# Compiler from the build tools.

My unit test project icon is displaying like a class library... how to fix?

I have 2 c# test projects in my VS2012 Update 1 solution, one shows a class library icon, one shows a test project icon. They both work as test project, but the discrepancy is driving me crazy. (short drive). Anybody know how to fix this? I've looked at the .csproj and the .sln files, but nothing is leaping out at me.

Right-click the project in Solution Explorer and choose Edit Project File
Add a new child in the <PropertyGroup> node:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Save your changes and close the file
Right-click the project in Solution Explorer and choose Reload Project
https://adamprescott.net/2012/03/29/convert-a-class-library-to-a-test-project-in-visual-studio/

If your project is on a new-style .csproj file (less verbose, says like <Project Sdk="Microsoft.NET.Sdk"> as the top line, supports globbing etc), then you can get a test tube icon for your project by either adding Microsoft.NET.Test.Sdk NuGet package to your project, or adding this line to your .csproj file (which amounts to the same thing):
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.6.1" />
</ItemGroup>
(Version number correct at the time of writing - check for what the latest is.)

Pawel's answer is right, but it was truncated by the html parser... Mentioned child node should look like:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
This line could be also directly added to the csproj file (to the main PropertyGroup).

This isn't really a solution, but it seems to be a bug in Visual Studio.
See Microsoft Connect issues here, here and here which you can follow.
There is also a similar question here.
UPDATE:
This seems to be resolved in Visual Studio 2013 preview.

Open up Solution Explorer, right-click, go to properties and under 'Application' there is a drop-down menu called 'Output Type' and change that from Class Library to whatever you want it (most likely an Application).

Visual Studio 2008: Start custom build target via project/solution context menu - without add-in

I have a custom build target in a visual studio 2008 c# project. Is there a simple way to add a context menu item to the project, so that the custom build target can be executed via the ide? The build target is not integrated into the default build process and has to be started by hand. This step should be simple for all developers and should not force them to execute msbuild from the command line.
Any hint for a simple, working solution?
regards,
Achim

Add a new configuration to the project/solution. Then, close the project file, and open it for editing in XML. Change it's DefaultTargets attribute to "PickBuild", and add the following target to the bottom of the file:
<Target Name="PickBuild">
<CallTarget Targets="Build" Condition=" '$(Configuration)' == 'Debug' "/>
<CallTarget Targets="Build" Condition=" '$(Configuration)' == 'Release' "/>
<CallTarget Targets="SpecialTarget" Condition=" '$(Configuration)' == 'NewConfiguration' "/>
</Target>
Now, to execute the special task, the developer just needs to switch configuration in Visual Studio and hit build. And, as requested, this lives within the file, so will work on anyone else's machine also

If you don't want an add-in, you could have a VS macro that registers a command (in the context menu of an item in the solution explorer), which launches this build process.

You can add another build configuration in addition to Debug and Release and then modify your project to use MSBuild conditions and properties to determine if your custom target should run based on the configuration being built. If you specify the chain appropriately, you should be able to prevent the default build operations occurring in favour of the custom steps you require.
To simplify for all developers, once you've created this special project file, you can export it as a template for use by the rest of the team when creating new projects.

While not contained inside of Visual Studio, I just create .cmd files. Inside of this file you use msbuild.exe to build the project. You can also specify properties and other command line options at the same time. When a developer needs to kick off a build they just double click on the correct .cmd file.

In this blog post Scott Hanselman describes how to create a button in VS to call "msbuild /m"
http://www.hanselman.com/blog/CategoryView.aspx?category=MSBuild
You can do the same, but instead you could call:
msbuild /t:YourTarget
You probably could automate the creation of the button.

Generating an Xml Serialization assembly as part of my build

This code produces a FileNotFoundException, but ultimately runs without issue:
void ReadXml()
{
XmlSerializer serializer = new XmlSerializer(typeof(MyClass));
//...
}
Here is the exception:
A first chance exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll
Additional information: Could not load file or assembly 'MyAssembly.XmlSerializers, Version=1.4.3190.15950, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
It appears that the framework automatically generates the serialization assembly if it isn't found. I can generate it manually using sgen.exe, which alleviates the exception.
How do I get visual studio to generate the XML Serialization assembly automatically?
Update: The Generate Serialization Assembly: On setting doesn't appear to do anything.

As Martin has explained in his answer, turning on generation of the serialization assembly through the project properties is not enough because the SGen task is adding the /proxytypes switch to the sgen.exe command line.
Microsoft has a documented MSBuild property which allows you to disable the /proxytypes switch and causes the SGen Task to generate the serialization assemblies even if there are no proxy types in the assembly.
SGenUseProxyTypes
A boolean value that indicates whether proxy types
should be generated by SGen.exe. The SGen target uses this property to
set the UseProxyTypes flag. This property defaults to true, and there
is no UI to change this. To generate the serialization assembly for
non-webservice types, add this property to the project file and set it
to false before importing the Microsoft.Common.Targets or the
C#/VB.targets
As the documentation suggests you must modify your project file by hand, but you can add the SGenUseProxyTypes property to your configuration to enable generation. Your project files configuration would end up looking something like this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<!-- Snip... -->
<GenerateSerializationAssemblies>On</GenerateSerializationAssemblies>
<SGenUseProxyTypes>false</SGenUseProxyTypes>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<!-- Snip... -->
<GenerateSerializationAssemblies>On</GenerateSerializationAssemblies>
<SGenUseProxyTypes>false</SGenUseProxyTypes>
</PropertyGroup>

This is how I managed to do it by modifying the MSBUILD script in my .CSPROJ file:
First, open your .CSPROJ file as a file rather than as a project. Scroll to the bottom of the file until you find this commented out code, just before the close of the Project tag:
<!-- To modify your build process, add your task inside one of the targets below and uncomment it. Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->
Now we just insert our own AfterBuild target to delete any existing XmlSerializer and SGen our own, like so:
<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<!-- Delete the file because I can't figure out how to force the SGen task. -->
<Delete
Files="$(TargetDir)$(TargetName).XmlSerializers.dll"
ContinueOnError="true" />
<SGen
BuildAssemblyName="$(TargetFileName)"
BuildAssemblyPath="$(OutputPath)"
References="#(ReferencePath)"
ShouldGenerateSerializer="true"
UseProxyTypes="false"
KeyContainer="$(KeyContainerName)"
KeyFile="$(KeyOriginatorFile)"
DelaySign="$(DelaySign)"
ToolPath="$(TargetFrameworkSDKToolsDirectory)"
Platform="$(Platform)">
<Output
TaskParameter="SerializationAssembly"
ItemName="SerializationAssembly" />
</SGen>
</Target>
That works for me.

The other answers to this question have already mentioned the Project Properties->Build->Generate Serialization Assemblies setting but by default this will only generate the assembly if there are "XML Web service proxy types" in the project.
The best way to understand the exact behaviour of Visual Studio is to to examine the GenerateSerializationAssemblies target within the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727**Microsoft.Common.targets** file.
You can check the result of this build task from the Visual Studio Output window and select Build from the Show output from: drop down box. You should see something along the lines of
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\sgen.exe /assembly:D:\Temp\LibraryA\obj\Debug\LibraryA.dll /proxytypes /reference:.. /compiler:/delaysign-
LibraryA -> D:\Temp\LibraryA\bin\Debug\LibraryA.dll
The key point here is the /proxytypes switch. You can read about the various switches for the XML Serializer Generator Tool (Sgen.exe)
If you are familiar with MSBuild you could customise the GenerateSerializationAssemblies target so that SGen task has an attribute of UseProxyTypes="false" instead of true but
then you need to take on board all of the associated responsibility of customising the Visual Studio / MSBuild system. Alternatively you could just extend your build process to call SGen manually without the /proxytypes switch.
If you read the documentation for SGen they are fairly clear that Microsoft wanted to limit the use of this facility. Given the amount of noise on this topic, it's pretty clear that Microsoft did not do a great job with documenting the Visual Studio experience. There is even a Connect Feedback item for this issue and the response is not great.

creating a new sgen task definition breaks a fly on the wheel. just set the needed variables to make the task work as intended. Anyway the microsoft documentation lacks some important info.
Steps to pre-generate serialization assemblies
(with parts from http://msdn.microsoft.com/en-us/library/ff798449.aspx)
In Visual Studio 2010, in Solution Explorer, right-click the project for which you want to generate serialization assemblies, and then click Unload Project.
In Solution Explorer, right-click the project for which you want to generate serialization assemblies, and then click Edit .csproj.
In the .csproj file, immediately after the <TargetFrameworkVersion>v?.?</TargetFrameworkVersion> element, add the following elements:
<SGenUseProxyTypes>false</SGenUseProxyTypes>
<SGenPlatformTarget>$(Platform)</SGenPlatformTarget>
In the .csproj file, in each platform configuration
e.g. <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
add the following line:
<GenerateSerializationAssemblies>On</GenerateSerializationAssemblies>
Save and close the .csproj file.
In Solution Explorer, right-click the project you just edited, and then click Reload Project.
This procedure generates an additional assembly named .xmlSerializers.dll in your output folder. You will need to deploy this assembly with your solution.
Explanation
SGen by default only for proxy types generates for “Any CPU”. This happens if you don't set the according variables in your project file.
SGenPlatformTarget is required to match your PlatformTarget. I tend to think this is a bug in the project template. Why should the sgen target platform differ from your project's? If it does you will get a runtime exception
0x80131040: The located assembly's manifest definition does not match the assembly reference
You can locate the msbuild task definition by analyzing your project file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
where MSBuildToolsPath depends on your <TargetFrameworkVersion> http://msdn.microsoft.com/en-us/library/bb397428.aspx
Look inside the SGen task definition for TargetFrameworkVersion 4.0 from
Windows installation path\Microsoft.NET\Framework\v4.0.30319\Microsoft.CSharp.targets
to see the undocumented variables like $(SGenPlatformTarget) you are free to set in your project file
<Target
Name="GenerateSerializationAssemblies"
Condition="'$(_SGenGenerateSerializationAssembliesConfig)' == 'On' or ('#(WebReferenceUrl)'!='' and '$(_SGenGenerateSerializationAssembliesConfig)' == 'Auto')"
DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource"
Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)"
Outputs="$(IntermediateOutputPath)$(_SGenDllName)">
<SGen
BuildAssemblyName="$(TargetFileName)"
BuildAssemblyPath="$(IntermediateOutputPath)"
References="#(ReferencePath)"
ShouldGenerateSerializer="$(SGenShouldGenerateSerializer)"
UseProxyTypes="$(SGenUseProxyTypes)"
KeyContainer="$(KeyContainerName)"
KeyFile="$(KeyOriginatorFile)"
DelaySign="$(DelaySign)"
ToolPath="$(SGenToolPath)"
SdkToolsPath="$(TargetFrameworkSDKToolsDirectory)"
EnvironmentVariables="$(SGenEnvironment)"
SerializationAssembly="$(IntermediateOutputPath)$(_SGenDllName)"
Platform="$(SGenPlatformTarget)"
Types="$(SGenSerializationTypes)">
<Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly"/>
</SGen>
</Target>

In case someone else runs into this problem suddenly after everything was working fine before: For me it had to do with the "Enable Just My Code (Managed Only)" checkbox being unchecked in the options menu (Options -> Debugging) (which was automatically switched off after installing .NET Reflector).
EDIT:
Which is to say, of course, that this exception was happening before, but when "enable just my code" is off, the debugging assistant (if enabled), will stop at this point when thrown.

I'm a little late to the party, but I found the previous answer difficult to work with. Specifically Visual Studio would crash whenever I tried to view the properties of my project. I figure this was due to the fact that it no longer understood how to read the csproj file. That said...
Add the following to your post-build event command line:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\sgen.exe" "$(TargetPath)" /force
This will leverage sgen.exe directly to rebuild the Xml Serialization assembly every time you build your project for Debug or Release.

Look in the properties on the solution. On the build tab at the bottom there is a dropdown called "Generate Serialization assembly"

A slightly different solution from the one provided by brain backup could be to directly specify the platform target right where you have to use it like so:
<!-- Check the platform target value and if present use that for a correct *.XmlSerializer.dll platform setup (default is MSIL)-->
<PropertyGroup Condition=" '$(PlatformTarget)'=='' ">
<SGenPlatform>$(Platform)</SGenPlatform>
</PropertyGroup>
<PropertyGroup Condition=" '$(PlatformTarget)'!='' ">
<SGenPlatform>$(PlatformTarget)</SGenPlatform>
</PropertyGroup>
<!-- Delete the file because I can't figure out how to force the SGen task. -->
<Delete Files="$(TargetDir)$(TargetName).XmlSerializers.dll" ContinueOnError="true" />
<SGen
BuildAssemblyName="$(TargetFileName)"
BuildAssemblyPath="$(OutputPath)"
References="#(ReferencePath)"
ShouldGenerateSerializer="true"
UseProxyTypes="false"
KeyContainer="$(KeyContainerName)"
KeyFile="$(KeyOriginatorFile)"
DelaySign="$(DelaySign)"
ToolPath="$(SGenToolPath)"
SdkToolsPath="$(TargetFrameworkSDKToolsDirectory)"
EnvironmentVariables="$(SGenEnvironment)"
Platform="$(SGenPlatform)">
<Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
</SGen>

For anyone interested in doing so for .NET Core - please refer to this MS article: https://learn.microsoft.com/en-us/dotnet/core/additional-tools/xml-serializer-generator
Basically, you just need to add one nuget package to your project.