Setting own ProductId or Version has no effect

[akordowski]

Setting a own ProductId or Version on the Calendar has no effect. The ProductId and Version properties are replaced on the serialization with the library meta data.

var calendar = new Calendar
{
    ProductId = "MyCalendarTool",
    Version ="1.0"
};

https://github.com/rianjs/ical.net/blob/6c03c42bd9e040622ffaa240be856dc531a20823/src/Ical.Net/Serialization/CalendarSerializer.cs#L25-L38

[akordowski]

@axunonb Closing without any comment on this? Can you say if it is a bug or do I make something wrong? If it is a bug is it fixed, will be it fixed or don't? Thank you in advance.

[axunonb]

We closed the issue after 3 years of inactivity.
As the ProductId has a setter, it could be expected, that changing would have an effect - which is not the case.
If you'd like to contribute a PR this is more than welcome.

[akordowski]

So the Version and ProductId properties are meant not to be changed? They should be then only getters, right?

[axunonb]

Correct. To clean up, we could make ProductId to only have a getter, or to process the value set correctly (ensure the specification)
We'd prefer the 2nd option, and a PR is appreciated.

[akordowski]

I would rather prefer to be able to override the properties with my own values. If the properties are not overridden then the library default values could be used. The specification don't states that it cannot be set to user values. At the moment it is an limitation by the library. What do you think?

[axunonb]

Changing the ProductId to a RFC-compliant value is fine.
With Version you are prone to get issues with client apps. They usually expect 2.0. So we won't open this to be changed. See LibraryMetadata.Version

[akordowski]

With Version you are prone to get issues with client apps. They usually expect 2.0. So we won't open this to be changed.

Ok, that makes sense. Then the Version property should be a getter with the default value.

Changing the ProductId to a RFC-compliant value is fine.

So it would be ok for you if the property could be set to a custom value?

[axunonb]

@minichma As there was no PR submitted by @akordowski I'll do that today.
I can't see a reason why changing the PRODID should be excluded, as the serialized string can be changed anyway.
TBD: I'd include the FileVersion dynamically, instead of using a fixed version literal (currently 4.0).