Errors porting from Spread 13 to Spread 18

Posted by: Peter.Priestley on 28 April 2025, 5:03 am EST

    • Post Options:
    • Link

    Posted 28 April 2025, 5:03 am EST

    We have a C++/CLI application exposing an FpSpread instance in CMFCWinFormsView.

    This compiles and runs successfully using Spread 13.

    Attempt to port to Spread 18 produces many errors like the following.

    D:\AsteroidSource\ASTEROID\trunk\ASTEROID\ClusterEditor.cpp(101,28): error C2371: ‘FarPoint::Win::Spread::FpSpread::_a’: redefinition; different basic types

    (compiling source file ‘/ClusterEditor.cpp’)

    D:\AsteroidSource\ASTEROID\trunk\ASTEROID\ClusterEditor.cpp(101,28):

    This diagnostic occurred while importing type ‘FarPoint::Win::Spread::FpSpread’ from assembly ‘FarPoint.Win.Spread, Version=18.0.20241.0, Culture=neutral, PublicKeyToken=327c3516b1b18457’.

    D:\AsteroidSource\ASTEROID\trunk\ASTEROID\ClusterEditor.cpp(101,28): error C2371: ‘FarPoint::Win::Spread::FpSpread::_b’: redefinition; different basic types

    (compiling source file ‘/ClusterEditor.cpp’)

    D:\AsteroidSource\ASTEROID\trunk\ASTEROID\ClusterEditor.cpp(101,28):

    This diagnostic occurred while importing type ‘FarPoint::Win::Spread::FpSpread’ from assembly ‘FarPoint.Win.Spread, Version=18.0.20241.0, Culture=neutral, PublicKeyToken=327c3516b1b18457’.

    D:\AsteroidSource\ASTEROID\trunk\ASTEROID\ClusterEditor.cpp(101,28): error C2373: ‘FarPoint::Win::Spread::FpSpread::_a’: redefinition; different type modifiers

    (compiling source file ‘/ClusterEditor.cpp’)

    I feel that I may have seen issues like this on earlier ports. Can anyone throw any light on this?

  • Posted 29 April 2025, 1:20 pm EST

    Hi Peter,

    We are currently investigating this issue. We will update you soon on this.

    Thanks & regards,

    Aastha

  • Posted 30 April 2025, 12:31 am EST

    Hi Aastha,

    I made a very simple example consisting of a User Control (FpSpread18ControlLibrary) and a test C++/CLI application (TestFpSpread18) using CWinFormsView that demonstrates this problem.

    I’ve attempted to attach the source here as zip files.

    Regards,

    Peter.

    FpSpread18ControlLibrary.zipTestFpSpread18.zip

  • Posted 30 April 2025, 10:40 pm EST

    Hi Peter,

    Thanks for sharing the samples.

    We have forwarded your concern to our developers. [Internal Tracking ID: SPNET-47342] We will update you on this as soon as we hear back from them.

    Thanks & regards,

    Aastha

  • Posted 17 June 2025, 1:14 am EST

    I am interested to know if there is any light at the end of the tunnel on this. Perhaps Spread does not support C++/CLI any more. Perhaps there is some code work around I could use?

    I would be interested in paying for priority support - but that does not seem to be available for Spread?

    Regards,

    Peter.

  • Posted 17 June 2025, 8:11 am EST

    Hi Peter,

    The developers have informed us that Spread now uses a new obfuscation tool called Babel Obfuscator to protect its DLLs. Since we don’t officially support C++/CLI, they don’t consider this a bug in Spread.

    However, after looking into it, the developers found that Babel Obfuscator has options to set prefixes for types, methods, properties, fields, and events. By adjusting these settings, they were able to build the project successfully on their side. The only issue they encountered was a runtime error: ‘Could not load file or assembly ‘MFCMIFC80’’ — this is not related to Spread.

    The good news is that the developers have fixed the compilation error, and the fix will be included in the upcoming v18SP2 build, which is expected to release by the end of July 2025.

    If you need priority support, you can consider upgrading to Platinum support by contacting our sales team:

    Tel: 1.800.858.2739 | 412.681.4343

    Fax: 412.681.4384

    Email: us.sales@mescius.com

    Thanks & regards,

    Aastha

  • Posted 17 June 2025, 8:31 pm EST

    Thank you Aastha! It is very informative to know the reason. I will look forward to the v18 sp2 release.

    Yes, MFCMIFC80 is a runtime dll required for some C++ MFC applications, so is not related to the problem.

    Now that I know what is going on, I think maybe I can get it to work by NOT calling fpSpread directly from C++/CLI, but by writing/using proxy methods in the C# User Control wrapper. Fortunately, my application design is trending like this anyway - the number of direct calls to fpSpread from C++/CLI is in the minority.

    Regards,

    Peter.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels