No native support (yet) for .NET Core 3.1 / .NET 5.0 ?

[StefH]

In a .NET 5.0 project I get this warning:

[sadomovalex]

hi @StefH
for .Net Core/.Net Standard it is quite tricky: check this issue #100.

[StefH]

hi @sadomovalex,

Actually, I'm a bit confused about this github project, there is only 1 csharp project : "Camlex.NET", where are all the Client projects ?

And also I cannot build the "Camlex.NET" because I'm missing the SharePoint dll, can't this be included via NuGet ?

[StefH]

@sadomovalex Aha!

I think I remember this: there is a separate "client" branch which contains the client code.... (I found some old emails from 2010 / 2012 where I found out I worked also on his project ....)

However, I still can't understand:

1. Why is the client developed in a separate branch ?
2. How to generate the different client dll's for all SharePoint versions? The source code contains only 1 project? --> I see that you use configurations for that.

[StefH]

Hi @sadomovalex,

It's very easy to create multiple project (which link the same source files) and create these new client projects using the new .csproj project, which can use mutliple targets, like <TargetFrameworks>net45;netcoreapp3.1;net5.0;netstandard2.0;netstandard2.1</TargetFrameworks>.

If you want I can make a PR for this.
However, I need to understand point 1 (above) first.

[StefH]

See #102

[sadomovalex]

Thank you for you PR Stef. I will review it and check how it matches all other requirements. Here are answers on your questions:

Why is the client developed in a separate branch ?

CSOM version is developed in separate branch because it was originally branched from basic server object model version.

How to generate the different client dll's for all SharePoint versions? The source code contains only 1 project? --> I see that you use configurations for that.

yes, correct - you have to use own configuration while source code base remains the same. Debug/Release configurations are for SP online.

Not sure the difference between 16 and 16.1
16 is for SP2016 onprem, 16.1 for Online

[StefH]

Hello @sadomovalex;

1. Did you have time to review my PR?

2. I think that the client branch could be merged into the main branch, there is no technical reason not do to ?

3. "16 is for SP2016 onprem, 16.1 for Online" --> Do you now support both versions?

[sadomovalex]

"16 is for SP2016 onprem, 16.1 for Online" --> Do you now support both versions?

yes. Moreover in the same VS solution (using the same codebase) it is possible to build CSOM version of client by just changing build configurations:

• Debug/Release - SPO
• Debug15/Release15 - SP2013 onprem
• Debug16/Release16 - SP2016 onprem
• Debug19/Release19 - SP2019 onprem

When you change build configuration - VS automatically changes referenced CSOM version (it is done via conditional referencing - you may check that if will edit csproj file and will see how CSOM references are added). This was the main reason of why .Net standard can't be natively added: on-prem versions should target .Net framework. I tried to explain that in the link provided above.

In you PR I see several different projects targeting different CSOM versions most probably. I'm not sure that will go this way (because want to keep the same codebase for all SP versions - it will reduce maintenance) but I will for sure review your PR in near future. Will let you know.

[StefH]

Note that the code-base (c# files) is 100% the same, I just use symbolic linking.

I did update the projects according to the correct usage from 16 and 16.1

[sadomovalex]

how do you think: is it possible to do having the same single csproj?

[StefH]

Yes, this is possible. You can also create a "new" .csproj project which uses the multiple build-configurations and switch the TargetFrameworks on these configurations.

However, this is a personal preference, I'm used to split the packages. (https://github.com/scottksmith95/LINQKit & https://github.com/zzzprojects/System.Linq.Dynamic.Core) which makes it more clear what is happening.

[sadomovalex]

Yes, this is possible. You can also create a "new" .csproj project which uses the multiple build-configurations and switch the TargetFrameworks on these configurations.

that sounds good and more close to the current architecture. Will investigate this option more deeply. Thank you for your help again!

[sadomovalex]

finally found time for addressing this task. Created new Sdk-style csproj and targeted multiple frameworks:

• .NET Framework 4.5
• .NET Standard 2.0
• .NET 5.0

It should cover most configurations (previous version targeted only .NET Framework 4.5).

Then figured out how to use the same conditional references logic when referenced CSOM assemblies depend on current build configuration in this new Sdk csproj:

• Debug/Release => CSOM SPOnline
• Debug15/Release15 => CSOM SP2013
• Debug16/Release16 => CSOM SP2016
• Debug19/Release19 => CSOM SP2019

For doing that I needed to recreate all Debug*/Release* configurations in new Sdk proj (with old ones conditional referencing didn't work) and tune a bit references themselves. Comparing with old csproj - now when you switch build configuration in VS you need to reopen solution. Only after that VS starts reference correct assemblies which correspond to selected build configuration (in old csproj references were updated in runtime on the fly without project reload). But I can live with that.

Mentioned changes are implemented in separate branch for now: https://github.com/sadomovalex/camlex/tree/feature/101-dotnet-standard.

Now most of technical issues are solved. Going to publish new Camlex.Client soon.

[StefH]

You did see my PR #102?

[sadomovalex]

yes, but like I wrote above I want to keep existing single-project approach with multiple build configurations. It is easier for me to maintain it like this (I have other projects organized the same way).

[sadomovalex]

Camlex.Client 5.0 with native support for .NET 5.0 and .NET Standard 2.0 has been released: https://sadomovalex.blogspot.com/2021/08/camlexclient-50-released-support-for.html