Options
  • Locked Locked
  • Replies 7 replies
  • Subscribers 7 subscribers
  • Views 657 views
  • Users 0 members are here
Related
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

shoeb
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

Parents
  • 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 ...
Reply
  • 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 ...
Children
No Data




              

© M-Files Corporation 2024 | Privacy Policy