System.PlatformNotSupportedException running in linux-based container

[rr-media]

Version: 3.0.0 - alpha3

I've just run console app in docker container and got the following PlatformNotSupportedException at the start . The same app works just fine under windows .NET Core 2.0.
Looks like it's one of Thread properties setter throws this (line number does not help for some reason).

Any ideas?

[16:44:51] [Info] [  ]Quartz.NET properties loaded from configuration file '/app/quartz.config'
[16:44:51] [Info] [  ]Registering datasource 'myDS' with db provider: 'Quartz.Impl.AdoJobStore.Common.DbProvider'
[16:44:51] [Info] [  ]Using object serializer: Quartz.Simpl.JsonObjectSerializer, Quartz.Serialization.Json
[16:44:51] [Info] [  ]Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
[16:44:51] [Info] [  ]Quartz Scheduler v.3.0.0.0 created.
[16:44:51] [Info] [  ]Using db table-based data access locking (synchronization).
[16:44:51] [Info] [  ]JobStoreTX initialized.
[16:44:51] [Info] [  ]Scheduler meta-data: Quartz Scheduler (v3.0.0.0) 'Service' with instanceId 'NON_CLUSTERED'
  Scheduler class: 'Quartz.Core.QuartzScheduler' - running locally.
  NOT STARTED.
  Currently in standby mode.
  Number of jobs executed: 0
  Using thread pool 'Quartz.Simpl.DefaultThreadPool' - with 10 threads.
  Using job-store 'Quartz.Impl.AdoJobStore.JobStoreTX' - which supports persistence. and is clustered.

[16:44:51] [Info] [  ]Quartz scheduler 'Service' initialized
[16:44:51] [Info] [  ]Quartz scheduler version: 3.0.0.0
[16:44:52] [Info] [  ]ClusterManager: detected 1 failed or restarted instances.
[16:44:52] [Info] [  ]ClusterManager: Scanning for instance "NON_CLUSTERED"'s failed in-progress jobs.
Host start was not succeeded: System.PlatformNotSupportedException: COM interop is not supported on this platform.
   at Quartz.Util.QueuedTaskScheduler..ctor(Int32 threadCount, String threadName, Boolean useForegroundThreads, ThreadPriority threadPriority, ApartmentState threadApartmentState, Action threadInit, Action threadFinally) in C:\projects\quartznet-6fcn8\src\Quartz\Util\QueuedTaskScheduler.cs:line 72
   at Quartz.Impl.AdoJobStore.ClusterManager.<Initialize>d__8.MoveNext() in C:\projects\quartznet-6fcn8\src\Quartz\Impl\AdoJobStore\ClusterManager.cs:line 36
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Quartz.Impl.AdoJobStore.JobStoreSupport.<SchedulerStarted>d__131.MoveNext() in C:\projects\quartznet-6fcn8\src\Quartz\Impl\AdoJobStore\JobStoreSupport.cs:line 493
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Quartz.Core.QuartzScheduler.<Start>d__68.MoveNext() in C:\projects\quartznet-6fcn8\src\Quartz\Core\QuartzScheduler.cs:line 371

quartz.config

quartz.scheduler.instanceName = AUTO
quartz.jobStore.clustered = true
quartz.scheduler.instanceName = Service
quartz.scheduler.idleWaitTime = 10000
quartz.scheduler.batchTriggerAcquisitionMaxCount = 10

quartz.threadPool.threadCount = 10

quartz.jobStore.type = Quartz.Impl.AdoJobStore.JobStoreTX, Quartz
quartz.jobStore.driverDelegateType = Quartz.Impl.AdoJobStore.MySQLDelegate, Quartz
quartz.jobStore.tablePrefix = QRTZ_
quartz.jobStore.dataSource = myDS
quartz.dataSource.myDS.connectionString = Server=localhost;Database=Service;uid=service;pwd=1
quartz.dataSource.myDS.provider = MySql
quartz.jobStore.useProperties = false

quartz.serializer.type = json

dockerfile

FROM microsoft/dotnet:2.0.0-preview2-runtime-stretch
WORKDIR /app
COPY . .
ENTRYPOINT ["dotnet", "Service.dll"]

[rr-media]

I've looked into this a bit deeper and it seems this row in QueuedTaskScheduler fails

_threads[i].SetApartmentState(threadApartmentState);

If I just comment this line out and rebuild it starts working. So looks like we should either have an ability to switch off this completely via configuration or just build netstandard 2.0 w/o THREAD_APARTMENTSTATE switch as quick work-around for now.

[lahma]

Thanks for the report and detailed investigation. I've pushed a fix for this. We really don't need to have THREAD_APARTMENTSTATE defined for .NET Core as that for COM interop.

[Layoric]

@lahma Awesome this has been fixed for beta-1, I've hit this while trying docker + .net standard 2.0 + quartz-net alpha3 as well. Would it be possible to get beta-1 published to AppVeyor NuGet feed or nuget itself so it can be referenced and used for testing?

[Siliconrob]

Would it be possible for you to release a new alpha to your nuget feeds with this included? There is a compounding issue here with MVC and locating local reference assemblies as is the case when compiling this from source and referencing this project dll. Your changes do fix this startup error.

It is a known issue with Cannot resolve assembly paths for reference compilation libraries and it appears .NET Core 2.1 which probably will have this fix although it is not going to be release till Q1 2018. If we were able to use the feed dlls again would make everything fit back together again in a seamless way and allow us to do more testing with .NET Core 2.0

[lahma]

I'll try to get release out next weekend the latest. I'm really trying to find possible breaking changes to be put to next release so that I could call it beta in good conscience. I'm sorry for the delay but I haven't had too much spare time recently.