-
Notifications
You must be signed in to change notification settings - Fork 162
Merging of dependencies to Pretzel.exe make developing plugins a pain #266
Comments
Note: this assembly merging stuff fails to work on mono as well. I'd really like if there were pretzel.logic packages in nuget, and I could start writing a plugin in a "clean room" manner, instead of having to hack a lot around. |
About the plugins: I know that right now it's a big pain, but with the master branch you have the possibility to use ScriptCs (through Pretzel.ScriptCs) which remove the need to reference Pretzel.exe. For the "one and unique exe" merge stuff, I was not here at the start of the project so I don't know why this is important but I think it's to simplify the use/installation of Pretzel. Otherwise, Fody seems to cause trouble in Mono (see #215), but we can try IL-Repack. |
I have tried a Fody + ILMerge based hybrid merging on my machine. It worked under windows, I'll try it under mono, and if it works well, I'll submit a PR. What I did: I Fody.Costura embed every assembly, except for Also I'm not sure if Fody didn't only hinder compilation impossible under mono. I have tried @vikingcode 's branch back then (and have borrowed the Fody related stuff from him in my above experiment), but I don't remember the details. Also note: ScriptCs is a no-go for me, as I'd like to write some unit tests for my stuff. When I work on that i'm too tired to write correct code, so instead I test! Fody.Costura merged assembly does not start up on Mono, most likely because of a mono bug |
Conceptually, this is something I still like. But clearly this isn't great for the extensibility side, so I'm not going to be dogmatically against keeping it this way. |
The way dependencies are currently merged to Pretzel.exe make it painful to develop plugins to Pretzel without compiling together with the Pretzel project. This actually defeats the purpose of plugins.
The problem is caused as all dependent packages are merged to the Pretzel.exe assembly, and are not included as Resouces containing the original Dll-s, and loaded by a custom loading mechanism.
An example I have encountered:
Pretzel.exe
as a reference to the project.System.IO.Abstractions.FileSystem
is passed on the component boundary.System.IO.Abstractions.TestingHelpers
IFileSystem
interface implemented theMockFileSystem
from the TestingHelpers is not the same as the one used bySiteContextenerator
, for example, as that is an interface with the same FQCN, but from a different assembly.I'm not totally amused by this "merged assembly" exe, as I see it causes more problems than having multiple files around, but probably this requirement is so strong that it must be kept. To solve these problems I think that only the classes in namespaces
Pretzel.*
should be "merged", other dependencies should be "embedded".I think someone with more knowledge about this Fody blackmagic can do this trivially, but if the issue stay open for a long time, eventually I'll give it a shot 😄
The text was updated successfully, but these errors were encountered: