Use modern async methods

[jaime-olivares]

I suggest to use async/await/Task rather than the old fashioned IAsyncResult/AsyncCallback. There is no AsyncResult class in the .net standard roadmap and thus it is not possible to use async operations as they are implemented now. See: https://msdn.microsoft.com/en-us/library/mt674882.aspx

[jcurl]

For .NET Standard, this is true. I still have to maintain .NET 4.0 compatibility, which wraps around the BeginXXX and EndXXX in a task. I can do this when I figure out how to compile the same source base for multiple frameworks. Unfortunately, we need a packages.config per project because that also contains a key for the targetFramework. This whole multiple frameworks is a complete mess in .NET made exponentially more complicated with NuGet... Sigh.

It is something I'm thinking about since i created the target net45, maybe I can build on the netstandard1.5 instead which might be more feasible to start.

[jcurl]

Well I'll be darned. After searching yesterday for a good hour I didn't find anything. Now I do. I think I've got a project structure that could work.

http://stackoverflow.com/questions/26396763/changing-packages-config-to-somethingelse-config

[adriantabacariu]

Hi! I saw your concerns on targeting/compiling the same source base on multiple .NET framework versions.

To achieve compilation of the same source base for multiple frameworks, you need to create multiple build configurations for each supported .NET version. After you have that, you can control which version is used for compilation and even what files to include/exclude for it (for more details http://stackoverflow.com/a/2928835). Nuget packages (and all references for that matter) can be included conditionally as well:

<ItemGroup>
  <Reference Include="RefName Version=2.0.0.0, Condition="'$(TargetFrameworkVersion)' == 'v4.5'">
    <HintPath>...\net45\...</HintPath>
  </Reference>
  <Reference Include="RefName Version=1.0.0.0, Condition="'$(TargetFrameworkVersion)' == 'v4.0'">
     <HintPath>...\net40\...</HintPath>
  </Reference>
</ItemGroup>

At this point, the process can be automated by calling MSBuild with /p:Configuration=DesiredConfiguration argument.

For creation of a single Nuget package that support multiple versions, you can create this folder structure and rely on the way Nuget references the correct version from a package (inside the package it matches the target framework to the folders in the \lib folder - see https://docs.microsoft.com/en-us/nuget/create-packages/creating-a-package#from-a-convention-based-working-directory)

[jcurl]

Thanks Adrian. The build.bat file does effectively the same thing but provides the details on the command line.

What you suggest will work for this project, but that's not the way I'm going to implement it, as it's not compatible with NuGet. NuGet can only have one packages.config per project and if you look in this file, there's an attribute called targetFramework. As soon as there's a different assembly depending on the framework being used, the above won't work.

It's also documented in MSDN that the VS IDE doesn't support more than one framework per project, despite these workarounds.

So the solution would be to create one SLN file per framework, one set of CSPROJ files per framework and one "packages.CSPROJNAME.config" per project. That separates everything cleanly, supports importing NuGet packages that might be dependent on the framework.

[adriantabacariu]

I see what you mean; it is indeed clean but I think it's also hard to maintain each sln/csproj/packages.config per framework.

I found one more resource about building Nuget packages for multiple target frameworks (http://stackoverflow.com/a/12936949). Is this of any help? I see you already have a nuspec file with the necessary file references - maybe the solution to this is somewhere in there.

[jcurl]

I've implemented the logic separating .Net 4.0 with .Net 4.5. Now the branch is ready to have .Net 4.5 specific code (and NetStandard1.5)

[schnitty]

Am wondering where this is at? I'm noting that if I install the nuget package into a .NETStandard project my calls to WriteAsync stall. Same code in a Full.NET project works fine Is this related to this? If so is this on the horizon or should I go with a full net project for now?

[jcurl]

.NET FX 4.0 is the version most tested. I don't know why there is a difference between netstandard and .net 4.0 (as 4.5 Async functions wrap properly the Begin/End methods and don't block).

I currently am busy with other software development projects which prevent me from providing more than bugfixes to .NET 4.0 for now.

[jcurl]

Closing as a duplicate to https://github.com/jcurl/SerialPortStream/issues/114 and https://github.com/jcurl/SerialPortStream/issues/116