Current filter:
                                You should refresh the page.
                                  • Hi Guys,

                                    today i wanted to play around with netcore and netstandard. so i tought i convert an basic module to netstandard - and leave the rest on netcoreapp. result is that i cannot start the application anymore. seems like some kind of DLL hell?

                                    System.TypeInitializationException: "The type initializer for 'DevExpress.LookAndFeel.UserLookAndFeel' threw an exception."
                                    MissingMethodException: Method not found: 'Void DevExpress.Utils.Text.StringParser.RegisterColorConverter(System.Drawing.ColorConverter)'.

                                    attached is the modified sample project - any suggestions?

                                2 Solutions

                                Creation Date Importance Sort by

                                We found another solution to share Class Libraries with the DevExpress.Data or DevExpress.Xpo dependencies for different Target Frameworks - Cross-platform targeting or Multi-Targeting. This approach helps you avoid two CSPROJ files for different Target Frameworks - less code duplication and maintenance for your solution. This is relevant if you want to share common code with the DevExpress-based .NET Core 3.0 WinForms and WPF apps and the projects that target .NET Framework 4.5, .NET Standard 2.0.

                                Attached is a working sample demonstrating this solution. The sample has the following structure and dependencies:

                                SharedClassLibraryWithMultiTargeting is a Class Library used in the .NET Core 3.0 and .NET Framework 4.5 Console apps.
                                To make it work, the CSPOJ file defines the TargetFrameworks element and required dependencies for each Target Framework using conditions.

                                <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFrameworks>netstandard2.0;netcoreapp3.0</TargetFrameworks> <Description>Sample project that targets multiple TFMs</Description> </PropertyGroup> <ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'"> <PackageReference Include="DevExpress.Xpo" Version="19.2.3" /> </ItemGroup> <ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp3.0'"> <PackageReference Include="DevExpress.WindowsDesktop.Xaf" Version="19.2.3-ctp" /> </ItemGroup> </Project>

                                The shared library contains a shared class, which may also contain framework-specific APIs using preprocessor directives if required.

                                using System; namespace SharedClassLibraryWithMultiTargeting { public class SharedClass { // APIs shared with all Target Frameworks. public string SharedProperty { get; set; } // APIs specific to Target Frameworks ( #if NETCOREAPP3_0 public string SharedMethod() => "SharedMethod call for .NET Core 3.0."; #elif NETSTANDARD2_0 public string SharedMethod() => "SharedMethod call for .NET Standard 2.0."; #endif } }

                                Please let us know how this works for your projects.

                                Hello Noxe,

                                As I noted in, there are some specificities that developers should take into account when they share .NET Standard 2.0 and .NET Core 3.0 Desktop libraries that depend on DevExpress APIs:

                                > More difficult code sharing if you create core libraries with the DevExpress.Data or DevExpress.Xpo assemblies. You may need to create 2 .csproj files: one for .NET Core 3.0 desktop apps and the other for .NET Standard 2.0 cross-platform apps.

                                Future solutions may include the following:

                                • Increase the minimally supported .NET version in DevExpress assemblies to 4.7.2. This way they will support .NET Standard 2.0 and can be used in .NET Core 3 apps with no problems.
                                • Refactor DevExpress.Data and other core libraries to have .NET Framework 4.5.2 and .NET Standard 2.0 versions. The latter can be used in .NET Core 3 apps with no problems.

                                More difficult solution in v19.1-2 is caused for the following reasons:

                                • Our assemblies are on .NET Framework 4.5.2 at the time of this writing.
                                • We cannot change the minimally supported .NET version too often due to existing customers and compatibility issues.
                                • The minimum .NET Framework version that supports .NET Standard 2.0 completely is 4.7.2 (
                                • Refactoring these libraries to separate this platform-dependent code in new assemblies is also a serious change for thousands of customers and even a greater number of their existing apps.
                                Show all comments
                                • Martin Praxmarer - DevExpress MVP 08.24.2019

                                  Thx Dennis - not quite the solution i had hoped for. currently thinking about postponing netcore3 tests.

                                  but i do not fully understand the problem yet. there are already netstandard DevExpress.Data / Xpo assemblies - so what exactly is the problem here?

                                • Dennis (DevExpress) 08.26.2019

                                  >there are already netstandard DevExpress.Data / Xpo assemblies - so what exactly is the problem here?

                                  The .NET Standard 2.0 version of DevExpress.Data is a stripped down version that is used primarily for XPO.

                                  This stripped down DevExpress.Data library does not contain code required for DevExpress WinForms and WPF components. For instance, take a look at the DevExpress.Data/Platform folder or look for the "DXPORTABLE" string inside the source code. I hope it is clearer now.

                                • Martin Praxmarer - DevExpress MVP 08.26.2019

                                  ok - thx Dennis, its clear now - but not really satisfying ;)

                                • Dennis (DevExpress) 08.26.2019

                                  Thanks for your feedback, Noxe - I think our teams will improve it when it becomes technically feasible for us and other customers. I am not a fan of the current behavior either. If you experience any other issues while sharing code as I suggested above, please let us know - thanks!

                                • Martin Praxmarer - DevExpress MVP 08.26.2019

                                  Thx Dennis - i think i will do some testing the next month in my sparetime - but i think it is not worth for anything in production this year - even when they release netcore 3. my fear with this approach currently is simply too much overhead for us...

                                • Dennis (DevExpress) 08.26.2019

                                  Got it, thanks!

                                • Martin Praxmarer - DevExpress MVP 10.04.2019

                                  Hi Guys,

                                  do you think there is a chance this will be changed in an reasonable timeframe? it seems currently this is the last showstopper for us. we are providing over 200 additional modules for our customers alongside our main solution - compiling all of them for 2 different platforms is not only a huge overkill for us, but will also be confusing for customers since they have to know where to use which module.

                                  in the end we would have our Win Client on core3 - an Web application on full framework, and other clients (admin) or win services - so our endusers will need to know where to use an core3 version of an module, and where to use an netstandard module... thats far from optimal.

                                  i also understand you might have other priorities - would just good to know if you have any solution on the radars!


                                • Dennis (DevExpress) 10.08.2019

                                  Hello Noxe,
                                  I am afraid you will not have a way to avoid 2 or 3 .csproj files with v19.1-2 this year if you want to create a class library with DevExpress.Data or DevExpress.Xpo and share it with the .NET Core 3.0 Desktop, .NET Framework 4.5 or .NET Standard 2.0 apps.
                                  We currently address the identification problem with naming and NuGet. For instance, our XPO NuGet package contains both .NET Framework 4.5 and .NET Standard 2.0 assemblies at the same time. We published separate packages for .NET Core 3.0 Desktop with the WindowsDesktop suffix.