Problem with configuration

Ok, can confirm that version updates to VAF-dependencies broke the configuration and by downgrading versions I got this working.

This set works for me:

<PackageReference Include="MFiles.Crypto">
<Version>24.4.3</Version>
</PackageReference>
<PackageReference Include="MFiles.VAF">
<Version>24.1.706.3</Version>
</PackageReference>
<PackageReference Include="MFiles.VAF.Configuration">
<Version>24.4.3</Version>
</PackageReference>
<PackageReference Include="MFiles.VAF.Configuration.Logging.NLog">
<Version>24.4.3</Version>
</PackageReference>
<PackageReference Include="MFiles.VAF.Extensions">
<Version>24.2.67</Version>
</PackageReference>
<PackageReference Include="MFilesAPI.Extensions">
<Version>23.3.2</Version>
</PackageReference>

And this breaks the configuration and along with it, recurring tasks:;

<PackageReference Include="MFiles.Crypto">
<Version>24.10.3</Version>
</PackageReference>
<PackageReference Include="MFiles.VAF">
<Version>24.5.714.1</Version>
</PackageReference>
<PackageReference Include="MFiles.VAF.Configuration">
<Version>24.10.3</Version>
</PackageReference>
<PackageReference Include="MFiles.VAF.Configuration.Logging.NLog">
<Version>24.10.3</Version>
</PackageReference>
<PackageReference Include="MFiles.VAF.Extensions">
<Version>24.10.73</Version>
</PackageReference>
<PackageReference Include="MFilesAPI.Extensions">
<Version>24.4.3</Version>
</PackageReference>

As there are multiple versions between those, can't say for sure what was the version where things broke, but I'll probably try updating later versions one-by-one to figure out what version breaks the configuration.

In general you should keep the package updates to be the same as those which are mandated by the nuget package (i.e. if MFiles.VAF requires exactly Interop.MFilesAPI version 24.6.2 then that is what you should have).

These restrictions are in place for exactly this reason.  In general nuget should respect those version requirements but there are ways and means to override it.

Yeah, sounds like that's the issue here. What is the "main" dependency that one can/should update to latest version and then have every other version according to its dependency constraints? Would it be perhaps the Interop.MFilesAPI or MFiles.VAF...?

So you're using the VAF Extensions, which has a specific version dependency for MFiles.VAF...  So in your case it's the VAF Extensions.  For other applications which don't use that library then it's likely to be the MFiles.VAF library which is the one that drives the dependency constraints.

So you're using the VAF Extensions, which has a specific version dependency for MFiles.VAF...  So in your case it's the VAF Extensions.  For other applications which don't use that library then it's likely to be the MFiles.VAF library which is the one that drives the dependency constraints.

I upgraded the dependencies to latest versions which I think should be compatible but the error returned again.

The dependencies that I have now are:
[net472]:
Top-level Package 
> MFiles.VAF.Extensions 24.10.73
> MFiles.VAF 24.10.720.1
> MFiles.VAF.Configuration.Logging.NLog 24.10.3
> MFilesAPI.Extensions 24.4.3
> Interop.MFilesAPI 24.10.3
> MFiles.Crypto 24.10.3
> MFiles.VAF.Configuration 24.10.3

Transitive Package Resolved
> Newtonsoft.Json 10.0.3
> NLog 5.0.1
> NLog.Database 5.0.1

And the dependency constraints seem to be:
For MFiles.VAF.Extensions:
- MFiles.VAF >= 24.5.714.1 so 24.10.720.1 should be ok
- MFiles.VAF.Configuration.Logging.NLog >= 23.12.3 so 24.10.3 should be ok
- MFilesAPI.Extensions >= 24.4.3 so 24.10.73 should be ok

For MFiles.VAF:
- Interop.MFilesAPI = 24.10.3 and that is there
- MFiles.Crypto = 24.10.3 and that is there
- MFiles.VAF.Configuration = 24.10.3 and that is there

For MFilesAPI.Extensions:
- Interop.MFilesAPI >=21.11.3 so 24.10.3 should be ok

As far as I can see, that all looks ok to me, but when I install the VAF to M-Files, the configuration breaks. I can't modify and save it anymore without getting that initial error that I posted.

Could you please review the above and maybe you can spot what is the problem with versions because as far as I can see, it all looks compatible according to version constraints. Even when I build the project, I get no errors from any version constraint violations so AFAIU, that also should confirm that all constraints are being followed properly.

I am on vacation but at first glance you look to be correct. I had a recollection that the Extensions had a specific-version constraint but it looks like that stopped a while ago.

I haven't translated the exception details but if you're able to provide a project that reproduced the issue then I can take a look at some point next week perhaps. The fix may be to reinstate the version requirement on the Extensions.

FYI: The Extensions library is not an official package so you could of course drop the use of that and just use the VAF directly, then work within those package constraints.

Alternatively, as the Extensions library is open-source, any issue/repro/pr to resolve the issue you've found would be appreciated. 

Ok, after doing some digging I can confirm that the bug was introduced in the latest version 24.10.73 of MFiles.VAF.Extensions. It works fine in 24.10.72!

So something broke wrt configuration and the recurring tasks definitions in extensions between those versions.

What I did was to remove all other M-Files related dependencies besides MFiles.VAF.Extensions and just let them come in as transitives. Not sure whey they were included as direct dependencies in the first place as I inherited this application from another consultant and they were there. But it seems to work just fine by having only MFiles.VAF.Extensions as direct dependency so that's enough for me.

Posted an issue to the GH project: Configuration issue introduced in v24.10.73 · Issue #141 · M-Files/VAF.Extensions.Community

Thank you for the report. It could well be a bug. I am out of the office for a few days though unfortunately. 

If you can share how you are defining that recurrence in your configuration (frequency vs whatever) then that would help. 

And also what you are changing the value to in the configuration?

All of this code runs through the same method to calculate the next-execution datetime.  It seems in some situations the code is returning null, which is not being handled somewhere.  I need to try to replicate "where".

I have created a preview release of the extensions with a possible fix.  I am on vacation on Monday and will not be able to look at this further, but if you can provide some more information on the issue (in the GitHub issue you created), and/or test the preview release, then I'd be grateful.

The release containing the possible fix is being uploaded to nuget now with version 24.10.0.6-issue-141.

I tested the fix and the bug is still there. I added some configuration that I have on the GH issue to help debug the issue.