The M-Files Community will be updated on Tuesday, April 2, 2024 at 10:00 AM EST / 2:00 PM GMT and the update is expected to last for several hours. The site will be unavailable during this time.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

breaking changes on update to nuget package 2.2.0.9

Hello,

I have a VAF application which has the following :
[list type=decimal]
  • Event Handlers

  • Auto calculated properties

  • Workflow state conditions

[/list]

I recently tried to update the nuget package of MFiles.VAF from 2.1.0.15 to 2.2.0.9 and it stopped working.
I get an error on calculation of auto calculated properties :

Object doesn't support this property or method: 'extension.GetPropertyCustomValue(...).Value'


Is there any other changes I need to make to upgrade to the latest version ?

I have checked the documentation :
developer.m-files.com/.../

I have updated the appdef.xml as follows :



type="server-application"
xmlns:xsi="">www.w3.org/.../XMLSchema-instance"
xsi:noNamespaceSchemaLocation="">www.m-files.com/.../appdef-server-v3.xsd">
20.5.0.0
false


but that doesn't help me much as we are not using Configuration.

Note:
We do not use MFiles.VAF.Extensions
We have written our own extensions.


Thanks,
Shoeb

  • Hi there,

    We have similar issue. We have new app developed with 2.2 and couple of old apps developed with 2.1. We have common functionality so we wanted to upgrade all applications. We broke old apps with exact error you describe.

    When we try to go back to 2.1 with new app, that new app is not working with older version of framework. So we are kind of stuck, we have new app with 2.2 and works only with 2.2 and other apps work only with 2.1. Very strange.

    It is not really clear why this happens, APIs did not change, only there is new support for multi-server mode which we don't use currently.
  • After some in-depth analysis, I have found out what caused this problem.

    It seems that Nuget update (to latest 2.2.0.9 version) updated the option "EmbedInteropTypes" to "True" (originally was set to "False" in older version 2.1.0.15). Here an example:



    ..\\packages\MFiles.VAF.2.2.0.9\lib\net45\Interop.MFilesAPI.dll
    True



    When I built our projects, I have found following warnings:


    CSC : warning CS1685: The predefined type 'FormattableString' is defined in multiple assemblies in the global alias; using definition from 'MFiles.VAF.Configuration, Version=2.2.0.9, Culture=neutral, PublicKeyToken=fa007b370d17fe5e'
    2>CSC : warning CS1762: A reference was created to embedded interop assembly 'Interop.MFilesAPI, Version=7.0.0.0, Culture=neutral, PublicKeyToken=f1b4733f444f7ad0' because of an indirect reference to that assembly created by assembly 'MFiles.VAF, Version=2.2.0.9, Culture=neutral, PublicKeyToken=fa007b370d17fe5e'. Consider changing the 'Embed Interop Types' property on either assembly.
    2>CSC : warning CS1762: A reference was created to embedded interop assembly 'Interop.MFilesAPI, Version=7.0.0.0, Culture=neutral, PublicKeyToken=f1b4733f444f7ad0' because of an indirect reference to that assembly created by assembly ', Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Consider changing the 'Embed Interop Types' property on either assembly.


    As Interop.MFilesAPI is used directly in our common VAF project but also in MFiles.VAF assembly, we would need to have the same 'Embed Interop Types' value on all of those assemblies.

    The easiest way is to change 'Embed Interop Types' to 'False' for 'Interop.MFilesAPI' on that specific project having it suddenly set on 'True' after Nuget update. Strangely, in our case Common project which references VAF and indirectly Interop.MFiles have on both packages 'Embed Interop Types' set on 'False'.
    But when we upgraded project which is referencing Common project and VAF directly, after upgrade 'Embed Interop Types' of 'Interop.MFilesAPI' was set on 'True' and problems start occurring because 'MFiles.VAF' and my Common assembly has 'Embed Interop Types' set on 'False' and they both have reference to 'Interop.MFiles' assembly.

    Interop.MFilesAPI is used to bridge communication from managed .NET code to unmanaged COM components and I assume that this could be optimization not to deploy large interop assemblies but to embed that part needed. See following https://stackoverflow.com/questions/20514240/whats-the-difference-setting-embed-interop-types-true-and-false-in-visual-studi.

    Long story short: setting Interop.MFilesAPI assembly and its property 'Embed Interop Types' back to 'False' solve the problem :). Curious to understand attention of changing it and why it does not apply equally in all projects.

    What worries me more is that VAF framework is as it seems stuck on .NET 4.5 and wondering why it is not progressing towards .NET 4.8. .NET 5 is around the corner also. I suppose that COM architecture is causing a problem to update smoothly but just my assumption ...
  • Hi,

    So, this is possibly a bug. I will check. Thank you for bringing this to our attention. The embed interop types feature does have an effect on a couple of items, from recollection, and I believed that the correct value used to be False. I wasn't made aware that this had changed, so I want to make sure that this isn't some sort of regression.

    I wanted to touch on your last point about .NET versions, though.

    We strive to make M-Files run on as many servers as we can and, until recently, the minimum required .NET version mandated by M-Files was 4.5. However, recently some services were updated and now 4.7.2 is now needed (as detailed here: www.m-files.com/.../System_requirements.html).

    Alongside this there has been a push to also update the VAF to target the 4.7.2 runtime. This work is blocked by a couple of other things but, when it happens, it'll also bring with it a couple of new goodies. I won't publicly estimate timeframes.

    In the interim, as the later 4.x framework runtimes are backwards compatible with 4.5 binaries, if you can guarantee that a later framework version exists in all the environments you use, then you can simply update your application to something later and reference the current VAF build from here. I am aware of a number of partners who have done so.

    Regards,

    Craig.
  • I cannot replicate your issue, dejan. I have just:


    • Created a VAF 2.2 application from the VS template (directly). "Embed Interop Types" is set to False for the API reference.

    • Created a VAF 2.1 application from the VS template, then upgraded it to VAF 2.2. "Embed Interop Types" is still set as False for the API reference.



    Regards,

    Craig.
  • Back to the original problem: this seems to be an issue in that an automatically-calculated property script isn't working correctly. The specific error you're seeing is because the VBScript proxy is trying to get the value from a VAF application, but it is failing.

    I can see a couple of potential issues:


    • There was an issue on startup/installation of your application. Remove it, check the VBScript proxies were removed properly, then reinstall. Check the Windows Event Log to see if there are any errors recorded.

    • There was an issue with something that your script returned. Attach a debugger and see whether your VAF code is actually called, runs successfully, and returns a valid type; if so then it could well be the Embed Interop Types flag.



    Regards,

    Craig.
  • Hi Craig,

    I just had the same issue and luckily I came across this thread.

    'Embed Interop Types' is magically set to True when you follow these steps:

    - Create VAF 2.2 application from VS template, 'MFiles.VAF' NuGet package 2.2.0.10 is installed. ('Embed Interop Types' is set to False)

    - Install the latest version of the 'MFiles.VAF.Extensions' NuGet package (1.2.11.5). This will automatically upgrade 'MFiles.VAF' package to 2.2.0.11. All fine by me.

    - Now you have 'Embed Interop Types' automatically set to True...!!! Grimacing

    When you first upgrade the 'MFiles.VAF' package to the latest 2.2.0.11 version and then install the extensions, the issue does not occur. Smile

  • Okay, the order of things should not affect the embed interop types flag on the API.  That's something I potentially need to look at, thank you for letting me know .

    That said: the way in which VAF 2.3 works is going to be a little different.  The actual API interop reference will now come from a new nuget package (Interop.MFilesAPI).  This is already in place with the VAF 2.3 (and VAF extensions 1.3) previews.