Can I use this in a package?

[PeteDuncanson]

I'm working on a package that needs a editor interface to some custom tables. For speed I'd love to just bundle Fluidity with it so I can get up and running quickly. However I'm worried about version clashes. What if I release a new version which uses a different version of Fluidity but the site its on has their own code which uses an older version of Fluidity.

Any ideas or thoughts on how to handle this sort of situation? Am I best of simply not using Fludity? Should I ILMerge it in? Could I assume that my package has to have Fluidity installed too separately? Not sure how best to approach it.

The simple answer might be "don't use this for packages" which I'd take. Wonder if there might be an option to "export" the files and configs that Fluidity creates, then I could just bundle those up and change them per version rather than having to have Fluidity generate everything on the fly each time...of course at this point I might be better off just hand rolling all those files anyway and all this goes away :)

Cheers

Pete

[mattbrailsford]

Hey Pete,

So what I would probably do is where possible use Nuget as this can maintain dependencies so you should be able to have a dependency on the Fuidity Nuget package.

For umbraco packages, this gets a bit harder, and I would advise not to embed Fluidity in your own package. I would suggest documenting as much as possible that Fluidity needs to be installed before hand, but then as a last resort, maybe have some code in you app startup that checks if Fluidity is installed before it attempts to use / reference the DLL at all. This should be possible by moving the Fluidity config to a seperate class and only calling a method on that class to configure, if the Fluidity dll is detected.

Obviously not ideal, but until we have dependency support in umbraco packages, this is really the best we can do.