search

eXpandFramework / eXpand

DevExpress XAF (eXpressApp) extension framework. 𝗹𝗶𝗻𝗸𝗲𝗱𝗶𝗻.𝗲𝘅𝗽𝗮𝗻𝗱𝗳𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸.𝗰𝗼𝗺, 𝘆𝗼𝘂𝘁𝘂𝗯𝗲.𝗲𝘅𝗽𝗮𝗻𝗱𝗳𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸.𝗰𝗼𝗺 and 𝘁𝘄𝗶𝘁𝘁𝗲𝗿 @𝗲𝘅𝗽𝗮𝗻𝗱𝗳𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 and or simply 𝗦𝘁𝗮𝗿/𝘄𝗮𝘁𝗰𝗵 this repository and get notified from 𝗚𝗶𝘁𝗛𝘂𝗯
http://expand.expandframework.com
Microsoft Public License
220 stars 114 forks source link

Today I got the same 'ReadModule with 2 Arguments' error on my Teamcity server (build is fine on my local computer). I solved it by deleting the Xpand.Xaf.* packages from the local nuget cache. I think there was a problem, because the old version converter (1.0.4?) patched the origin dlls (instead of using separate VersionConverter.v.$DxVersion.DoNotDelete folders. #436

Closed apobekiaris closed 5 years ago

apobekiaris commented 5 years ago

Today I got the same 'ReadModule with 2 Arguments' error on my Teamcity server (build is fine on my local computer). I solved it by deleting the Xpand.Xaf. packages from the local nuget cache. I think there was a problem, because the old version converter (1.0.4?) patched the origin dlls (instead of using separate VersionConverter.v.$DxVersion.DoNotDelete folders. Unfortunately there are now other issues with VersionConverter. Imho VersionConverter creates more problems than it solves.... But in fact I don't really understand the the concept of the VersionConverter: The Xpand.Xaf. modules shouldn't be bound to a specific DevExpress Version, therefore VersionConverter is used to patch references, right? But what happens on breaking changes in DX code? It is still necessary to release a new version of the Xpand.Xaf modules, isn't it?

Originally posted by @krombipils in https://github.com/eXpandFramework/eXpand/issues/435#issuecomment-500953247

apobekiaris commented 5 years ago

let's discuss it here

apobekiaris commented 5 years ago

@krombipils

I think there was a problem, because the old version converter (1.0.4?) patched the origin dlls (instead of using separate VersionConverter.v.$DxVersion.DoNotDelete folders.

I cannot follow you here, please provide more details so I can address the issue.

Unfortunately there are now other issues with VersionConverter.

VersionCOnverter is now on version 27 meaning that many problems are already addressed and the package is becoming stable.

But in fact I don't really understand the the concept of the VersionConverter: The Xpand.Xaf.* modules shouldn't be bound to a specific DevExpress Version

Due to many the years supporting and following DevExress releases it became obvious to me that I spent the majority of my time migrating to new versions while my code base does not change much. VersionConverter addresses this problem. To make you easier to understand it even handles the major versions where the DevExpress assemblies name change. Meaning that soon I will have the majority of my time to invest it in more productive areas than version migration and by I I also include the package consumers since their version will no change they do not have to migrate.

But what happens on breaking changes in DX code? It is still necessary to release a new version of the Xpand.Xaf modules, isn't it?

yes true but only for the packages that are affected and from my experience there are almost zero. The majority of the released packages use XAF api that did not change the last 6-7 years. But even if there is a breaking change at some point there is reflection, emit and many other ways we can address those issues making the latest version of the package available to the majority of the users that are stuck in the past because they do not have the resources to follow versions.

is refection and those non strongly typed approaches trust-able? yes they are cause there are tests. The compiler is a tool that help you write faster however dynamic modules are by far more powerful and target a broader audience.

apobekiaris commented 5 years ago

also do not underestimate the power of nuget and its version and distribution architecture all versionconverter packages are distributed only as nugets.

This is how I see the picture of creating a better universe for XAF and not with large frameworks that is scary to migrate through versions.

Looking forward for your thoughts.

apobekiaris commented 5 years ago

A few more point for reference.

in an average project I expect only few packages to be consumer, take as an example the ExcelImport which has dependencies to eXpandFramework System, System.Win, System.Web, Base, Xpo, Utils.

Step by step all dependecies are removed and now it depends to these 6 versionconverter enabled packages.

https://github.com/eXpandFramework/eXpand/blob/6deb9088ff3ea570123234ac7e18fe462d9fcbf6/Xpand/Xpand.ExpressApp.Modules/ExcelImporter/ExcelImporterModule.cs#L36-L41

and when the ModelMapper released https://github.com/eXpandFramework/eXpand/issues/434

then ExcelImporter will depend to only 7 standlone well tested/ documented packages and can be come one of them and consumed from XAF versions 3 years ago to 3 years after.

krombipils commented 5 years ago

Thank you for the very detailed explanations. I need some time to fully understand them and to check what's really going wrong on my teamcity server

krombipils commented 5 years ago

I'm still struggling with the build issues on my server. My first assumption that it is related to an older versionconverter version was wrong. I can repro my problems like this: 1) Delete xpand.xaf.modules.reactive from nuget package folder 2) Restore nuget packages 3) Run VersionConverter .\Xpand.VersionConverter.ps1 C:\Users\andre\source\repos\XafLibs\Xaf.Utils\Xaf.Utils.csproj -> Checking C:\Users\andre\.nuget\packages\xpand.xaf.modules.reactive\1.2.31\lib\net4.6.1\Xpand.XAF.Modules.Reactive.dll references.. References: mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System.Reactive, Version=4.1.0.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263 DevExpress.ExpressApp.v18.2, Version=18.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a 0Harmony, Version=2.0.0.0, Culture=neutral, PublicKeyToken=c52ffed5d5ff0958 System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Fasterflect, Version=2.1.3.0, Culture=neutral, PublicKeyToken=38d18473284c1ca7 System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a Checking DevExpress.ExpressApp.v18.2, Version=18.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a reference... DevExpress.ExpressApp.v18.2 version will changed from 18.2.7.0 to 19.1.3 Patching C:\Users\andre\.nuget\packages\xpand.xaf.modules.reactive\1.2.31\lib\net4.6.1\Xpand.XAF.Modules.Reactive.dll C:\Users\andre\.nuget\packages\xpand.versionconverter\1.0.27\build\Xpand.VersionConverter.ps1 : ErrorRecord : Ausnahme beim Aufrufen von "Write" mit 1 Argument(en): "Die Datei "C:\DevExpress.ExpressApp.v19.1.dll" konnte nicht gefunden werden."

VersionConverter/MonoCecil is searching for DevExpress.ExpressApp.v19.1.dll in c:. Of course this is wrong, because it is located in C:\Users\andre.nuget\packages

4) If I run VersionConverter again, I'm getting the ReadModule with 2 Arguments/ Symbols do not match error, because Xpand.XAF.Modules.Reactive.pdb is modified, although there was an error in the previous run

apobekiaris commented 5 years ago

very helpful!!

may i see your csproj as well to help me speed up my fix?

krombipils commented 5 years ago

`

net461

`

krombipils commented 5 years ago

There is also a package reference to VersionConverter 1.0.27 in my directory.build.props

apobekiaris commented 5 years ago

There is also a package reference to VersionConverter 1.0.27 in my directory.build.props

what do u imply? where the relation u see?

krombipils commented 5 years ago

I tried to ensure that the most recent VersionConverter is used (due to the issues with PackageReferences in older versions). Maybe this is not a good idea, because there might be also projects in the solution not depending on VersionConverter.

krombipils commented 5 years ago

The build/VersionConverter is running fine, after I installed DX 19.1.3 assemblies in the GAC

apobekiaris commented 5 years ago

I tried to ensure that the most recent VersionConverter is used (due to the issues with PackageReferences in older versions). Maybe this is not a good idea, because there might be also projects in the solution not depending on VersionConverter.

versionconverter patches only assemblies with naming Xpand.XAF.Modules

krombipils commented 5 years ago

I found another, related issue (if VersionConverter is not running on all projects in the solution): There is an issue if one of the Xpand.Xaf. modules is indirectly referenced by a project. 1) Project 1 (with indirect references) is built. VersionConverter won't run. Xpand.Xaf. module dll is copied to target dir by _CopyFilesMarkedCopyLocal target, e.g. to ~\bin 2) Project 2 (with direct reference) is build. VersionConverter runs and tries to fix refernces for Xpand.Xaf. modules. Due to $targetPath\$([Path]::GetFileName($packageFile))", $packageFile | ForEach-Object { it first searches for Xpand.Xaf. dll in target dir. Xpand.Xaf. dll can be found at this place, but the Xpand.Xaf. pdb is missing -> Error is thrown.

I fixed the problem by re-enabling VersionConverter target for all solutions in directory.build.props

apobekiaris commented 5 years ago

but the Xpand.Xaf.* pdb is missing

how this can be missed?

This is what i tried.

  1. Create an empty XAF solution and install a few Xpand.XAF packages to the agnostic module and build.
  2. Remove the agnostic module from the solution and use a direct reference to it for the platform dependent module.
  3. Build the platform depend and both the pdb and the dll are in bin

can you provide repro details?

expand commented 5 years ago

The DevExpress.XAF repository includes commits that relate to this task:

Please update the related Nuget packages and test if issues is addressed. These are nightly nuget packages available only from our NugetServer.

If you do not use the Xpand.XAF.Modules directly but through a module of the main eXpandFramework project, please wait for the bot to notify you again when integration is finished or update the related packages manually.

Thanks a lot for your contribution.

apobekiaris commented 5 years ago

the scearion is now addressed as mono.cecil throws many symbol related exception types, for this case it was a SymbolNotFound and the scipt now handles all symbol related exceptions.

This will probably address all indirect problems, however if you still have issues please provide clear instuction on how to create the indirect problem and we can sure address it as well.

krombipils commented 5 years ago

can you provide repro details?

Sorry, I need some time to check what's going on...

apobekiaris commented 5 years ago

This will probably address all indirect problems, however if you still have issues please provide clear instuction on how to create the indirect problem and we can sure address it as well.

this comment was for 1.0.29 which is not published yet.

Sorry, I need some time to check what's going on...

sure take your time

expand commented 5 years ago

The DevExpress.XAF repository includes commits that relate to this task:

Please update the related Nuget packages and test if issues is addressed. These are nightly nuget packages available only from our NugetServer.

If you do not use the Xpand.XAF.Modules directly but through a module of the main eXpandFramework project, please wait for the bot to notify you again when integration is finished or update the related packages manually.

Thanks a lot for your contribution.

expand commented 5 years ago

Closing issue for age. Feel free to reopen it at any time.

.Thank you for your contribution.