Open tlhintoq opened 7 years ago
I don't have the source code in front of me right now, but if I remember correctly the UWP implementation should be able to select the correct Timer. Have you explicitly added a reference to Shim in your UWP application?
Sent from my iPhone
On 4 jan. 2017, at 15:45, tlhintoq notifications@github.com wrote:
When I use a System.Timer from PCL, it throws an exception when running the UWP project.
However... Since Microsoft released a proper System.Timer NuGet there doesn't seem to be a need to 'shim it' any longer. https://www.nuget.org/packages/System.Threading.Timer/
In the mean time, is there a way to force the loading of the timer from the Microsoft assembly instead of the Shim assembly?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
@anders9ustafsson Not sure what you mean by explicity adding the reference. But I didn't add anything beyond installing the package.
I installed the Shim package through Visual Studio NuGet Package Manager. It was then installed to the PCL, iOS ,Droid, UWPpackages. It does appear as a reference in each of those packages: FYI: The UWP package has 2.1.0-pre installed, the others 2.0.1 Could that be the issue?
I remember correctly the UWP implementation should be able to select the correct Timer.
Ok.. Select it where/how? Because in code I only specify System.Timers.Timer
and don't see a way to specify where it would get that from Shim or from the MS nuget package.
@tlhintoq For the bait-and-switch technique to work, you need to have matching assembly versions. Please consolidate Shim to version 2.1.0-pre in all your projects and try again.
What I meant with selection in this case is that the platform-specific implementation of Shim contains a type-forwarding directive to the type implementation in the specific platform's standard libraries.
The UWP standard libraries do contain System.Threading.Timer
, and type-forwarding to this type is supported in the UWP version of Shim. You do not need to reference the new .NET Core based library to support System.Threading.Timer
.
System.Timers.Timer
on the other hand is not supported in UWP's standard libraries, so UWP Shim will fallback on the PCL implementation of System.Timers.Timer
. Not sure if there is a .NET Core implementation of System.Timers.Timer
available?
@anders9ustafsson I notice that 2.1.0-pre no longer appears in Visual Studio's NuGet package manager even with the checkbox for prelease ticked. It is also no longer appearing on the NuGet page. Has this been pulled? Is this still the latest -pre version I should test with?
@tlhintoq Yes, for some reason 2.1.0-pre was unlisted? I can't remember that I have unlisted it myself, so I have now re-listed it. Thanks for notifying me.
@tlhintoq After looking more closely into the project file for UWP, it indeed does seem like the System.Timers.Timer
implementation has been omitted. Will fix this. Many thanks for reporting!
When I use a System.Timer from PCL, it throws an exception when running the UWP project. However... Since Microsoft released a proper System.Timer NuGet there doesn't seem to be a need to 'shim it' any longer. https://www.nuget.org/packages/System.Threading.Timer/
In the mean time, is there a way to force the loading of the timer from the Microsoft assembly instead of the Shim assembly?