[SOLVED] How to set target platform to .NET Framework in Monogame 3.8?

Perhaps look for the change comparisons? No?

I have already watched. I serialized MemoryStream and ConstructorInfo in level binary file. It is important for my game. But in .NET Core they marked as “not serializable”.

Now we are getting somewhere, what is it you are trying to do? Load data?

Yes. I try deserialize the level data from a file. And it has serialized MemoryStream and ConstructorInfo.

Hopefully, someone can chime in to assist with that now.

Ok. But does Monogame 3.8 support only .Net Core?

Not the person to ask.

This may or may not help. I recently decided to try Load/Save in my game using serialisation.

I hit a problem because Color, Vector2 etc were not serialisable.

I used the solution here:

https://answers.unity.com/questions/772235/cannot-serialize-color.html

The idea is to create another class SerialisableColor which replaces Color in the code but can be cast to Color when needed.

This solved the issue for me but those 2 classes are pretty simple.

It’s possible to still target .Net Framework in MonoGame 3.8. I ported a project to 3.8 that still targets .Net Framework 4.5.2. I am building from source though, not sure what the options are with Nuget.
The MonoGame.Framework.WindowsDX project I’m referencing targets both, .Net Core and .Net Framework. This is possible by having this in the csproj file:

<TargetFrameworks>net452;netcoreapp3.1</TargetFrameworks>

For MonoGame.Framework.DesktopGL .Net Standard is used instead of .Net Core:

<TargetFrameworks>netstandard2.0;net452</TargetFrameworks>

I just checked the MonoGame source, since I didn’t remember messing with the csproj files myself. The current source version has .Net Framework support without modification, as you can tell by the
TargetFrameworks tag:

2 Likes

I believe you are referring to this part which is not shown here due to truncation…

  <ItemGroup>
    <PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.0">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Version="4.0.1" Include="SharpDX" />
    <PackageReference Version="4.0.1" Include="SharpDX.Direct2D1" />
    <PackageReference Version="4.0.1" Include="SharpDX.Direct3D11" />
    <PackageReference Version="4.0.1" Include="SharpDX.DXGI" />
    <PackageReference Version="4.0.1" Include="SharpDX.MediaFoundation" />
    <PackageReference Version="4.0.1" Include="SharpDX.XAudio2" />
    <PackageReference Version="4.0.1" Include="SharpDX.XInput" />
  </ItemGroup>

EDIT

I have lost track of what .NET Framework, Standard and Core are now… I am right that they are three different things, right?

Thanks a lot. I set target platform to net471

Now I have that line in my .csproj file:
<TargetFramework>net471</TargetFramework>

And my game works fine. I used DesktopGL template for my game and i have only netcore3.1 in the .csproj file. But i added that line and game works fine. But i don’t know this is a good way or a dirty trick…

Should I add “netstandard2.0;net452” to the target platform? Or can I leave only net471?

1 Like

Nope, I was referring to this line on top:

<TargetFrameworks>net452;netcoreapp3.1</TargetFrameworks>
  • .Net Framework is the old, less platform independent way. It requires a separate installation of the .Net Framework
  • .Net Core is the new, more platform independent way. It does not require a separate installation, you just ship what you need with your app.
  • .Net Standard is the common ground that supports both. It’s interesting for creating a library that can be consumed by .Net Core as well as .Net Framework projects.
1 Like

It sounds reasonable that the template would go with .Net Core, as it’s the future of .Net.

I think you’re good. No need to add stuff you don’t want to target.

OH, I did not see this part…

Concerning the .NET stuff…

As long as my XNA / MG stuff works, I think I can ignore most of it and just learn what needs learning, but all this fracturing is starting to feel a lot like Android…

Thanks for the explanation though :sake:

Yeah, but I think it’s just a temporary transition period. The idea is that with .Net 5 everything will become one again, at least that’s what I heard.

1 Like

Annoyingly I have no idea what to study for .NET as a result, so I am stuck with 4.5 2012… as my base knowledgebase…

Don’t worry about it. The stuff you learn with 4.5 will transfer just fine to future frameworks.

1 Like

It’s the stuff that don’t that worry me, MS Docs are atrocious unless you understand them…

It’s very hard to tell which direction MS is taking things. Sure, .NET 5 is supposed to bring everything together, but until it does, it’s pretty hard to bet on it. I’m sticking with framework for Windows systems until I see what .NET 5 really means. Framework 4.7.2 comes with Win10 for the last few versions, so that one is pretty safe for modern systems.

1 Like