not all serializers can handle the current format of ScheduledTask. For example the fact that it is internal.
So serializers have to do stuff like this
static class ScheduledTaskHelper
{
static Type scheduledTaskType = typeof(IMessage).Assembly.GetType("NServiceBus.ScheduledTask");
static PropertyInfo taskProperty;
static PropertyInfo nameProperty;
static PropertyInfo everyProperty;
static ConstructorInfo constructor;
public static Type WrapperType = typeof(ScheduledTaskWrapper);
static ScheduledTaskHelper()
{
constructor = scheduledTaskType.GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public, null, Type.EmptyTypes, null);
taskProperty = scheduledTaskType.GetProperty("TaskId");
nameProperty = scheduledTaskType.GetProperty("Name");
everyProperty = scheduledTaskType.GetProperty("Every");
}
public static bool IsScheduleTask(this Type messageType)
{
return messageType == scheduledTaskType;
}
public static ScheduledTaskWrapper ToWrapper(object target)
{
var taskId = (Guid) taskProperty.GetValue(target, null);
var name = (string) nameProperty.GetValue(target, null);
var timeSpan = (TimeSpan) everyProperty.GetValue(target, null);
return new ScheduledTaskWrapper
{
TaskId = taskId.ToString("D"),
Name = name,
Ticks = timeSpan.Ticks,
};
}
public static object FromWrapper(ScheduledTaskWrapper target)
{
var instance = constructor.Invoke(null);
taskProperty.SetValue(instance, Guid.ParseExact(target.TaskId, "D"));
nameProperty.SetValue(instance, target.Name);
everyProperty.SetValue(instance, TimeSpan.FromTicks(target.Ticks));
return instance;
}
}
@Particular/nservicebus-maintainers can u think of a better way to handle this? ie instead of making it public
I guess the "safer" approach would be to handle this as some kind of control message and end the pipeline before deserialization? But this seems to be quite a big and maybe risky change, so making it public sounds like a valid workaround.
How about moving it out of the core first?
How about moving it out of the core first?
that also sounds like something we would do in a major version?
that also sounds like something we would do in a major version?
Agreed, let's make it public now and raise an issue to move the scheduler out?
@mauroservienti I remember that you had some ideas for a external scheduler?
Most helpful comment
I guess the "safer" approach would be to handle this as some kind of control message and end the pipeline before deserialization? But this seems to be quite a big and maybe risky change, so making it public sounds like a valid workaround.