Skip to content
This repository was archived by the owner on Jun 25, 2020. It is now read-only.

Merging of dependencies to Pretzel.exe make developing plugins a pain #266

Closed
kodfodrasz opened this issue Aug 27, 2015 · 4 comments
Closed

Comments

@kodfodrasz
Copy link
Contributor

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:

  1. I start writing a plugin project, and need reference to some Pretzel API types.
  2. I add Pretzel.exe as a reference to the project.
  3. I write a class that interfaces a Pretzel class from an 3rd party dll. Example: System.IO.Abstractions.FileSystem is passed on the component boundary.
  4. I want to write a test to the plugin, using System.IO.Abstractions.TestingHelpers
  5. I notice that the strong name of the IFileSystem interface implemented the MockFileSystem from the TestingHelpers is not the same as the one used by SiteContextenerator, for example, as that is an interface with the same FQCN, but from a different assembly.
  6. I cry in pain.

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 😄

@kodfodrasz
Copy link
Contributor Author

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.
Maybe simply having Pretzel.API assembly in NuGet, which Pretzel projects would also depend on would be nice. But I'm not sure how many people try to develop plugins to pretzel without docs, and with these hardships.

@laedit
Copy link
Member

laedit commented Aug 28, 2015

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.
And for the doc, I plan to do it since a while but I haven't got the time...

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.
@JakeGinnivan, @shiftkey do you think that the merge in one exe is still important?
Since it's cause trouble on mono and with the plugins I think that we could stop to do it.

Otherwise, Fody seems to cause trouble in Mono (see #215), but we can try IL-Repack.

@kodfodrasz
Copy link
Contributor Author

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 Pretzel.Logic, to the Pretzel.exe.
I ILMerge the Pretzel.Logic.dll to Pretzel.exe

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

@shiftkey
Copy link
Member

do you think that the merge in one exe is still important?

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants