NTS as PortableFramework setup

[GoogleCodeExporter]

I've tried to set-up a portable framework solution of the NTS stack.
The main issue is the use of SerializableAttribute throughout the suite.

Maybe we can subsequently replace
[Serializable]

with
[DataContract], [DataMember]

Original issue reported on code.google.com by felix.ob...@netcologne.de on 29 Mar 2012 at 7:19

• Blocked on: #183, #184

[GoogleCodeExporter]

There is also the option to exclude it [Serializable] with:
#if PortableClassLibrary
This would mean another build, but the PCL version could replace the 
Silverlight and WindowPhone versions. And there is hope that MonoDroid and 
MonoTouch will support PCL.

Another alternative is to use XmlSerialization, and then we could have just one 
build to rule them all. I don't have a clear picture of the use cases for 
Serializable.

Original comment by pauldend...@gmail.com on 24 Jul 2012 at 10:25

[GoogleCodeExporter]

>Another alternative is to use XmlSerialization, and then we could have just 
one build >to rule them all. I don't have a clear picture of the use cases for 
Serializable.
It's hard to me to remember, I fear that the Serializable attribute it's used 
only to make NTS usable inside SqlServer 2008, that it's a thing I've used some 
years ago.

To me: +1 for the macro directive.
If we can use only a macro and remove Silverlight and WindowPhone versions, I 
think the project can be heavily simplified.

Original comment by diegogu...@gmail.com on 2 Dec 2013 at 1:32

[GoogleCodeExporter]

IIRC the serializeable attribute is applied where classes are marked as 
serializable in jts.

Newtonsoft.Json could be a source of inspiration on how serialization could be 
done.

Original comment by felix.ob...@netcologne.de on 2 Dec 2013 at 2:01

[GoogleCodeExporter]

Maybe protobuf-net is another option (fast)

Original comment by Gennadiy.Donchyts on 2 Dec 2013 at 3:42

[GoogleCodeExporter]

Original comment by felix.ob...@netcologne.de on 9 Dec 2013 at 9:39

• Changed state: Started

[GoogleCodeExporter]

If you agree with using macro directive I can tag current repository version 
and remove projects other that regular framework and PCL framework.
To me, felix work with PCL projects looks ok.
Anyone disagree?

Original comment by diegogu...@gmail.com on 14 Feb 2014 at 9:50

[GoogleCodeExporter]

Fine with me

Original comment by john.d...@newgrove.com on 14 Feb 2014 at 9:53

[GoogleCodeExporter]

I see some commits in nts_pcl branch like r1162.
Anyway, PCL code that is now in trunk looks perfectly working.
We have the tag for 1.13.2 that contains also code for Silverlight, MonoDroid 
and WinPhone. So I wanna delete this code and leave only standard and PCL code, 
hoping to not make mistakes...

Original comment by diegogu...@gmail.com on 4 Mar 2014 at 2:22

[GoogleCodeExporter]

Ok.

Please do not remove the [Serializable] attribute, instead place it in 
conditionals. This is ugly but otherwise we might as well ditch the .Net 
Framework version as well.

Once we have the same functionality realized with [DataContract]/[DataMember], 
we can remove [Serializable] with a new version

Original comment by felix.ob...@netcologne.de on 4 Mar 2014 at 8:21

[GoogleCodeExporter]

>Please do not remove the [Serializable] attribute, instead place it in 
conditionals.
+1
For now I plan to remove all projects that aren't PCL and plain .NET.
Then I can check for all Seializable attributes, but to me looks that your work 
already do that.

Original comment by diegogu...@gmail.com on 5 Mar 2014 at 8:04

[GoogleCodeExporter]

with r1172 I've terminated the cleanup phase, all looks ok in my machine, from 
solution builds to msbuild BuildRelease.
If someone experienced build issues, please let me know.

Other steps that I need to do soon:
1. fix #macro to remove #silverlight and #winphone/#monodroid
2. chech [Serializable] attributes
3. fix nuget packaging

Original comment by diegogu...@gmail.com on 5 Mar 2014 at 9:34

[GoogleCodeExporter]

Just a note: the only way I see to update correctly GeoAPI folder INSIDE the 
trunk is to delete manually the folder and then update the repository. If you 
experience issues building GeoAPI (geoapi.snk missing) probably you also need 
to do this.

Original comment by diegogu...@gmail.com on 5 Mar 2014 at 9:14

[GoogleCodeExporter]

code committed, there's an issue with 2.0 build that I hope to fix soon.

Original comment by diegogu...@gmail.com on 5 Mar 2014 at 10:04

[GoogleCodeExporter]

2.0 build fixed with r1177

Original comment by diegogu...@gmail.com on 6 Mar 2014 at 8:14

[GoogleCodeExporter]

felix made some great developments with r1186, r1187 and r1188. now looks the 
(I hope) only problems are related to serialization

Original comment by diegogu...@gmail.com on 17 Mar 2014 at 5:08

[GoogleCodeExporter]

Serialization issues resolved with r1191 (on my machine).
Could parties interested please confirm.

The serializer used is System.Runtime.Serialization.DataContractSerializer.

@ben.abelshausen: could you bring in ProjNet.Pcl from the pcl branch you worked 
in?

Original comment by felix.ob...@netcologne.de on 18 Mar 2014 at 11:24

[GoogleCodeExporter]

> could parties interested please confirm
Looks all ok to me. well done felix :)
As you may know, there are some code that should be tested against 
serialization?
I mean, to be sure to not having lost any DataMember/KnownType attributes?

Original comment by diegogu...@gmail.com on 18 Mar 2014 at 11:54

[GoogleCodeExporter]

>As you may know, there are some code that should be tested against 
serialization?
- One could argue that the geometry factory should have the 
DataContract/DataMember attributes also.
- The classes in the Features namespace might be worth looking at.

Original comment by felix.ob...@netcologne.de on 18 Mar 2014 at 12:06

[GoogleCodeExporter]

Checking now...

Met vriendelijke groeten,

Original comment by ben.abel...@gmail.com on 18 Mar 2014 at 12:07

[GoogleCodeExporter]

One thing we need to resolve is how we deal with the PCL classes in the NuGet 
packages.
There are two options:
- provide a separate package for the PCL set
- change the packages to use .Net assemblies for .Net20 to .Net35 and PCL for 
later

Any other ideas?

I must admit that I would like to go for the first option as my other dear 
project SharpMap would probably break if it had to rely on the PCL assemblies 
because there are no Serializable attributes anymore!

Original comment by felix.ob...@netcologne.de on 19 Mar 2014 at 8:50

[GoogleCodeExporter]

Isn't it possible to just add the PCL version to the current package without 
getting in the way of the non-PCL usecases?

For example include net40 and portable-net40+sl4+win8+wp7 profiles? (just 
examples, did not look at the real profiles we would have to use)

Original comment by ben.abel...@gmail.com on 19 Mar 2014 at 8:56

[GoogleCodeExporter]

To me, we can move "slowly" and create separate PCL set, at least for a couple 
of releases. Maybe we try a unified package for next SharpMap releases?

Original comment by diegogu...@gmail.com on 19 Mar 2014 at 8:56

[GoogleCodeExporter]

Ok, let's create a separate package... Doesn't really make much of difference 
anyway.

It looks like I'm finally going to be able to start working on integrating some 
of the NTS-capabilities into OsmSharp... :-)

Original comment by ben.abel...@gmail.com on 19 Mar 2014 at 9:26

[GoogleCodeExporter]

it is possible to put all versions in one package like Ben mentioned. nuget 
will choose the one that is most appropriate. in some cases the choise can be a 
bit surprising though. so maybe a separate package is better.

Original comment by pauldend...@gmail.com on 19 Mar 2014 at 11:50

[GoogleCodeExporter]

Hi guys,

What are the todo's here? I can add a new nuget package *.PCL and we can close 
this issue! ;)

Original comment by ben.abel...@gmail.com on 18 Apr 2014 at 6:54

[GoogleCodeExporter]

I submitted a patch for a PCL nuget package for GeoAPI:

https://geoapi.codeplex.com/SourceControl/list/patches

Is there agreement on this way of doing things?

Original comment by ben.abel...@gmail.com on 23 Apr 2014 at 11:32

[GoogleCodeExporter]

I'll check

Original comment by diegogu...@gmail.com on 23 Apr 2014 at 12:17

[GoogleCodeExporter]

applied with some minor changes with r74253. hope to intecrate inside msbuild 
soon

Original comment by diegogu...@gmail.com on 23 Apr 2014 at 12:31

[GoogleCodeExporter]

Nice thanks!

Will do something similar for NTS...

Original comment by ben.abel...@gmail.com on 23 Apr 2014 at 12:48

[GoogleCodeExporter]

some work done with r1217, hope TeamCity allow PCL builds...

Original comment by diegogu...@gmail.com on 23 Apr 2014 at 12:56

[GoogleCodeExporter]

added also GeoAPI.PCL nuget packaging to teamcity.targets, with r1221

Original comment by diegogu...@gmail.com on 23 Apr 2014 at 1:19

[GoogleCodeExporter]

@diego: What's the plan? The codebetter server doesn't seem to support this?

I just tested on my own TeamCity instance and there the PCL-stuff does build.

Original comment by ben.abel...@gmail.com on 23 Apr 2014 at 1:49

[GoogleCodeExporter]

>The codebetter server doesn't seem to support this?
I fear that teamcity server doesn't have necessary dependencies for PCL (same 
for previous WinPhone/SL builds)
To me this isn't a blocking issue, we simply should verify manually that all 
code compile, launching manually msbuild scripts

Original comment by diegogu...@gmail.com on 23 Apr 2014 at 1:58

[GoogleCodeExporter]

I keep a build running anyway, will report issues with the PCL builds here. I 
just added the new BuildReleasePCL target:

http://build.osmsharp.com:8080/viewLog.html?buildTypeId=NtsPortableClassLibrary_
Nts&buildId=2854

I also created a patch for the NTS.PCL package.

Original comment by ben.abel...@gmail.com on 23 Apr 2014 at 2:20

Attachments:

• pcl.patch
• pcl_powercollections.patch

[GoogleCodeExporter]

It may be a case of bundling the contents of C:\Program Files 
(x86)\MSBuild\Microsoft\Portable or equivalent in a tools dir and updating the 
build targets in the csproj file. No idea if that contravenes any licensing 
though

Original comment by john.d...@newgrove.com on 23 Apr 2014 at 2:33

[GoogleCodeExporter]

tried with guest to access TeamCity and I see 
"You do not have enough permissions to access build type with id: 
NtsPortableClassLibrary_Nts"

anyway, interesting builds are also UnitTestsPCL and NugetPackPCL

Original comment by diegogu...@gmail.com on 23 Apr 2014 at 2:33

[GoogleCodeExporter]

applied patch with r1223 :)

Original comment by diegogu...@gmail.com on 23 Apr 2014 at 2:50

[GoogleCodeExporter]

about teamcity issues, maybe I made a mistake with targets file, let me check

Original comment by diegogu...@gmail.com on 23 Apr 2014 at 2:51

[GoogleCodeExporter]

Sorry about that guest access was not enabled on the NTS project.

Original comment by ben.abel...@gmail.com on 23 Apr 2014 at 2:57

[GoogleCodeExporter]

no problem, of course. only to say.

Original comment by diegogu...@gmail.com on 23 Apr 2014 at 3:35

[GoogleCodeExporter]

Is GeoAPI Suppored under PCL?  It won't install for me with NuGet under Xamarin 
(Android).

Original comment by kjeremy@gmail.com on 13 May 2014 at 5:18

[GoogleCodeExporter]

>Is GeoAPI Suppored under PCL? 
New packages are not yet released. 

Original comment by diegogu...@gmail.com on 15 May 2014 at 6:34

[GoogleCodeExporter]

Original comment by felix.ob...@netcologne.de on 15 May 2014 at 7:06

• Now blocked on: #183, #184

[GoogleCodeExporter]

Fixed with r1258

Original comment by felix.ob...@netcologne.de on 13 Aug 2014 at 4:09

• Changed state: Fixed