How to compile it in vs2017 with target frameowrk to .net 3.5

[Qtan75]

Hi,
I am trying to rebuild this library to target framework .net 3.5. However, when I got to the right clicked project name Protobuf-net, properties, application tab, the target framework field is grayed out and can not be changed.

Is there a way to set the target framework to .net 3.5?

Thank you!

[mgravell]

I'll hack the csproj this evening and create a 3.5 target. Basically, the problem is: - VS2017 can target 3.5 - dotnet CLI can't - I want the project to be trivially buildable via dotnet CLI I suspect I can add a different config that includes 3.5 support for use when building in VS.

…

On 10 Jun 2017 6:53 p.m., "Qingfeng Tan" ***@***.***> wrote: Hi, I am trying to rebuild this library to target framework .net 3.5. However, when I got to the right clicked project name Protobuf-net, properties, application tab, the target framework field is grayed out and can not be changed. Is there a way to set the target framework to .net 3.5? Thank you! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#262>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsHNdOJ0MKAvSb5wJwWDprHzavBYvks5sCtgDgaJpZM4N2Laj> .

[Qtan75]

Hi,
Thanks for the response!

[Qtan75]

Hi,
Is it in the csproj file, just need to change:
net40;netstandard1.3
to
net3.5;netstandard1.3

I can give it a try now.

Thank you!

[mgravell]

Yep; see this commit that I've made to the "parser" branch: 26f56e7 - anything similar should work. If you just want it for your local build, just change the targetframework to whatever you need

…

On 10 June 2017 at 19:44, Qingfeng Tan ***@***.***> wrote: Hi, Is it in the csproj file, just need to change: net40;netstandard1.3 to net3.5;netstandard1.3 I can give it a try now. Thank you! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#262 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsNkfkNI_d3zd143snsy5dD5-DGv9ks5sCuQJgaJpZM4N2Laj> .

-- Regards, Marc

[Qtan75]

It works! Thanks!

[Qtan75]

So after I created the dll from the vs2017 build, with target framework of .Net3.5. Ireferenced it in a Windows Mobile 6.5 application. But unluckily, that WM6.5 application had errors after I have reference the new dll. The first error is:
The type 'System.Xml.Serialization.IXmlSerializable' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Another question I have is: Is it possible to convert this package (protobuf-net) to a vs2008 solution and build it with target frame .Net3.5 in there?

Thank you!

[mgravell]

On the first: did you try adding a reference to System.Xml? This sounds like the nuget pack problem that should be fixed soon - basically, the nuget pack tooling fails to properly record framework dependencies, so downstream references aren't added when needed. You should be able to add manually while that gets fixed. On VS2008: is it possible: absolutely! but: not by me. I don't have VS2008 and have no intentions of installing VS2008 or supporting VS2008. However, it shouldn't be necessary. I'd rather understand what the thing is that makes you want VS2008 to build this.

…

On 12 June 2017 at 20:04, Qingfeng Tan ***@***.***> wrote: So after I created the dll from the vs2017 build, with target framework of .Net3.5. Ireferenced it in a Windows Mobile 6.5 application. But unluckily, that WM6.5 application had errors after I have reference the new dll. The first error is: The type 'System.Xml.Serialization.IXmlSerializable' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken= b77a5c561934e089'. Another question I have is: Is it possible to convert this package (protobuf-net) to a vs2008 solution and build it with target frame .Net3.5 in there? Thank you! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#262 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsDZY0KnWKcShfo8Ho3_TOCGyfu9Zks5sDYvCgaJpZM4N2Laj> .

-- Regards, Marc

[Qtan75]

The protobuf-net dll was used for an application developed in vs2008. So has the error happened in. Yes, System.xml is in reference, but the version is 3.5.0.0 for this application. However in the protobuf-net solution, it reference to a version of 2.0.0.0 for the System.Xml it is using.

Since vs2008 is used for my application, so that's why I was trying to build the protobuf-net.dll in vs2008. thought this could but actually may not.

[Qtan75]

When I tried to remove the System.Xml version 2.0.0.0 referenced in the protobuf-net solution, it gave an error:

[mgravell]

I've checked the csproj, and xmlserializer isn't in there explicitly, except for the .net core builds; however, what you're seeing sounds like something that an assembly binding redirect should be able to solve. Again, these are usually added automatically by nuget, but for the issue (that is being fixed, but it is a MS thing) with framework deps in dotnet cli. See https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/bindingredirect-element - you should be able to copy the required values directly out of the error message.

…

On 12 June 2017 at 21:59, Qingfeng Tan ***@***.***> wrote: When I tried to remove the System.Xml version 2.0.0.0 referenced in the protobuf-net solution, it gave an error: [image: image] <https://user-images.githubusercontent.com/17502718/27054839-699df83c-4f90-11e7-9da7-0ef933de7826.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#262 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsD0K3mX_VhyHcgs27r0fYte1bN2Aks5sDaaWgaJpZM4N2Laj> .

-- Regards, Marc

[mgravell]

btw, if you want the full gory details: NuGet/Home#4853 On 12 Jun 2017 11:02 p.m., "Marc Gravell" <marc.gravell@gmail.com> wrote: I've checked the csproj, and xmlserializer isn't in there explicitly, except for the .net core builds; however, what you're seeing sounds like something that an assembly binding redirect should be able to solve. Again, these are usually added automatically by nuget, but for the issue (that is being fixed, but it is a MS thing) with framework deps in dotnet cli. See https://docs.microsoft.com/en-us/dotnet/framework/ configure-apps/file-schema/runtime/bindingredirect-element - you should be able to copy the required values directly out of the error message.

…

On 12 June 2017 at 21:59, Qingfeng Tan ***@***.***> wrote: When I tried to remove the System.Xml version 2.0.0.0 referenced in the protobuf-net solution, it gave an error: [image: image] <https://user-images.githubusercontent.com/17502718/27054839-699df83c-4f90-11e7-9da7-0ef933de7826.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#262 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsD0K3mX_VhyHcgs27r0fYte1bN2Aks5sDaaWgaJpZM4N2Laj> .

-- Regards, Marc

[Qtan75]

So I have tried adding a line:

<PackageReference Include="System.Xml" Version="3.5.0.0" />

into the csproj xml, however, then vs2017 shows build errors:
Unable to resolve 'System.Xml (>= 3.5.0)' for '.NETFramework,Version=v3.5'.
Unable to resolve 'System.Xml (>= 3.5.0)' for '.NETFramework,Version=v4.5.2'.
Unexpected dependency 'System.Xml' with no version number.

Any insights on those?

[mgravell]

Yeah, this isn't a package reference on regular .NET; it is a framework reference. Try:

<Reference Include=System.Xml" />

It is, however, a package reference in .NET core. Build tools are fun :/ I have fun Condition markers to do things like this, for example in protobuf-net itself:

  <ItemGroup Condition="'$(ImportLibs)|$(FeatureServiceModel)' == 'net|true'">
    <Reference Include="System.ServiceModel" />
    <Reference Include="System.Configuration" />
    <Reference Include="System.Runtime.Serialization" />
  </ItemGroup>
  <ItemGroup Condition="'$(ImportLibs)' == 'core'">
    <!-- could make this more granular to respect the options, but no need yet -->
    <PackageReference Include="System.Reflection.Emit" Version="4.3.0" />
    <PackageReference Include="System.Reflection.Emit.ILGeneration" Version="4.3.0" />
    <PackageReference Include="System.Reflection.Emit.Lightweight" Version="4.3.0" />
    <PackageReference Include="System.Reflection.TypeExtensions" Version="4.3.0" />
    <PackageReference Include="System.Xml.XmlSerializer" Version="4.3.0" />
    <PackageReference Include="System.Runtime.Serialization.Primitives" Version="4.3.0" />
  </ItemGroup>

However, I'm slightly confused because IIRC System.Xml is actually included by default. Sheesh.

The fact is the build tools are a bit of a mess right now (for .NET / .NET core generally, not this library specifically). It is causing me pain on a number of projects. Fixes are in the pipelines, but are outside of my control.

[Qtan75]

Ok, I have changed it to:

However, under the Dependencies, Assemblies, The System.Xml is still 2.0.0.0. I will need 3.5. It's strange because the System.Xml.Linq is 3.5.

But now the build error is gone.

[mgravell]

If you're targetting .NET 3.5, then it is System.Xml 2.0; .NET 3.5 are incremental additions to .NET 2.0 via additional assemblies; the base assembles do not change (except for bugfixes etc, but they didn't increase the major version).

Because System.Xml.Linq is one of those additions in .NET 3.5, it gets the 3.5 versioning; however System.Xml: does not - it stays 2.0

In .NET 4.0, they all become 4.0.

[Qtan75]

got it. However, in the other project that uses this protobuf-net.dll, it has a System.Xml reference version of 3.5. So we were wondering if that could help.

Thanks for the help!

[mgravell]

AFAIK (and I'm happy to be corrected): System.Xml 3.5 does not exist.. at least, not in regular .NET. If it exists in some Mono / Unity / whatever branch, then fine.

[mgravell]

Closing issue; 2.3.0 will include 2.0 and 3.5 builds via the "VS" configuration (that only works in VS, hence the name)