I sparked this off last night on twitter, but I don't think it was the ideal forum for the discussion, so thought I'd move it over to the forums where it can be discussed in full.
So, last night I was working on an new package action for installing mime types, which I have working how I need it. As part of my package then, I just include the PackageActionsContrib.dll which holds this new package action and it all works. Sweet!
But then I came across a problem. What if another package developer doesn't upgrade to the latest version of the PAC dll? Say someone installs my package with the latest code, but then installs another package with an older version of the code. This other dll no longer holds the package action I need. The problem now is, if the user decides to uninstall my package, parts of my package will not be able to uninstall. Worse still, it will look like the issue is with my package, and not the other developers.
I can only see this issue getting more compounded as more and more people use the PAC project (and lets admit it, why wouldn't they, it's a great project).
The only way I can see around this, is rather than including the PAC.dll in your package, instead, you use PAC more as a snippets library which you copy to your package (If you do this, I'd probably recommend changing the package actions alias). This way you can guarantee that your package action will always be available while your package is installed.
What do you guys think? Has anybody got any other suggestions? or am I just making a mountain out of a molehill?
Hi Matt, I agree with you on this one. As Package Action Contrib is still in it's infancy however as Umbraco becomes popular and the increase of packages that become available then I see this becoming more and more of a problem.
I would agree with Matt on this one and would probably suggest the following:
Use Package Actions Contrib as a snippet library
Copy actions you need into your own class/DLL
Give the actions unique names, by maybe prefixing the action with something unique like the package name?
I would love to hear everyone else's thoughts on this please.
My Add404Handler action isn't included in the PAC project yet, while I submitted a patch. So if you have a version without that handler and with your own stuff added, the 301 URL Tracker won't uninstall anymore ;-)
We should get Richard Soeteman here, I think he is one of the Project Admins... Asked him on Twitter (maybe he is on holiday?).
I agree that depending on the PAC dll is an issue that any package developer using it should be aware of.
As you pointed out Matt there is an issue with versions and uninstall. And i'm sure that these kinds of dependencies could potentially break any Umbraco solution.
I usually create install code as part of my own code, and the PAC project is a great source of inspiration for this. And for me it will always be a great source of inspiration, but I would never include it directly in my own package simply because of the potential install and uninstall issues.
As long as there is no way of registering package dependencies in Umbraco I see no other way.
There are 2 ways to look at Package Action Contrib:
As an installer only. Perform the actions and get the hell outta there!
As both installer/uninstaller. Which is where the problem lies.
As suggested, since Package Action Contrib can be overwritten, then the only way to guarantee the uninstall actions to work is compile those package actions directly into your own assemblies.
Don't forget that not all packages use .NET assemblies, so Package Action Contrib is still useful to them.
A compromise would be to have a collection of C# class/scripts that could be included in the App_Code folder. That way each package action is a separate file/script/class.
@Lee, not a bad idea regarding App_Code, but there is still the potential for it getting overwritten. ie, I've just submitted a patch that adds IIS7 support to the AddHttpHandler. If an older one was installed that replaced my updated one, then again, I wouldn't be able to uninstall completley.
If it was to go that route, I think something would need to be built in to prevent it overwritting newer versions. Not sure how you'd go about that though =)
Using your AddHttpHandler action as an example Would it break the install? really?
If the old version of AddHttpHandler would add an IIS6-friendly HttpHandler... and your new version added both the IIS6 and IIS7 handlers ... then surely the uninstall/undo would remove both HttpHandler sections? I can't see where it would break the install.
If your new action borks over not being about to find the IIS7 handler, then isn't that down to poor code/logic?
No, the other way around. He updates the AddHttpHandler. Then another package get's installed with an older version of the AddHttpHandler. When you uninstall the first package, it won't remove the IIS7 HttpHandler anymore...
This is a tricky one, what are the chances of PAC being a core part of Umbraco ?
Thinking out loud - if including PAC in package, it could be coppied rather than included by the package generator so that it's not included the uninstall process, (would also have to check to ensure it's not replacing a newer version), although only takes one package not to adopt this strategy for it to fail, so not really practical.
Only other thing I can think of (which would require some dev, and I'm not even sure is possible) would be to change how PAC works so that when you install a package that uses PAC, it actualy goes and downloads the latest DLL from a trusted source. Obviously this would require everyone who uses it currently to update their packages, but all new ones should work.
Again, I'm not sure how viable an option this is though.
If we'd going to use a trusted shared source to keep the assembly centralized, it has to be updated a lot! Say I creat a new Action, how will I get it in the assembly at the trusted shared source? By waiting a few days?
Package dependency is something we discussed at the retreat. No solution came from the chats, but its absolutely worth revisiting.
The example we used was Warren's CWS - as it uses XSLTsearch ... should it use the latest version? How to integrate the dependency? At creation of the package? at install time? (thats risky because it's untested - so then we're looking at specifying stable releases for the dependency)
Was on a holiday for a few weeks. Great topic with No easy answer. The idea behind the contrib project was to give the user a few extra Actions that they could use without having to compile anything in Visual Studio, A lot of Umbraco devs don't have Visual Studio or a .net development background. When we first started the project nobody implemented the UnInstall option. That's required now btw. Anyway it's a great tool out of the box for installing packages. For Uninstall you can't 100% rely on the dll. Even if we come up with a solution for versioning etc. If the user installs a package with the same PAC dll and Unistall both packages 1 package will uninstall fine, the other will not because the PAC dll is gone. So if you want to be 100% sure (well that is 98% because a lot can go wrong in the Uninstall process) you can include the sourcecode into your own dll.
On the other hand how many people will install a package on a real environment and UnInstall that? I always use a test environment and when I need to have that one cleaned up, I reinstall Umbraco.
1) You could probably version, compile, and link your own version of the contrib lib and register it in the GAC using the GAC API. Of course this would only work in full trust but that way you could have multiple versions of the same assembly around and with your code linking a specific version you'd get the one you want. We might be talking pure theoretical here though because the hassle is probably too big to actually go ahead and do it..
2) An easier option would be to add an option for overriding the action names and compile your own version of contrib under a different name. With that in place each package can deploy their own version of contrib side by sde and refer to the action by the name + the overriding identifier.
Instead of referring to GrantPermissionForApp you'd refer to GrantPermissionForApp_MyPackge which resides in PackageActionContrib_MyPackage.dll.
Best way to use Package Actions Contrib?
Hi Guys,
I sparked this off last night on twitter, but I don't think it was the ideal forum for the discussion, so thought I'd move it over to the forums where it can be discussed in full.
So, last night I was working on an new package action for installing mime types, which I have working how I need it. As part of my package then, I just include the PackageActionsContrib.dll which holds this new package action and it all works. Sweet!
But then I came across a problem. What if another package developer doesn't upgrade to the latest version of the PAC dll? Say someone installs my package with the latest code, but then installs another package with an older version of the code. This other dll no longer holds the package action I need. The problem now is, if the user decides to uninstall my package, parts of my package will not be able to uninstall. Worse still, it will look like the issue is with my package, and not the other developers.
I can only see this issue getting more compounded as more and more people use the PAC project (and lets admit it, why wouldn't they, it's a great project).
The only way I can see around this, is rather than including the PAC.dll in your package, instead, you use PAC more as a snippets library which you copy to your package (If you do this, I'd probably recommend changing the package actions alias). This way you can guarantee that your package action will always be available while your package is installed.
What do you guys think? Has anybody got any other suggestions? or am I just making a mountain out of a molehill?
Cheers
Matt
Hi Matt,
I agree with you on this one. As Package Action Contrib is still in it's infancy however as Umbraco becomes popular and the increase of packages that become available then I see this becoming more and more of a problem.
I would agree with Matt on this one and would probably suggest the following:
I would love to hear everyone else's thoughts on this please.
Warren :)
Well this is a problem indeed :-)
My Add404Handler action isn't included in the PAC project yet, while I submitted a patch.
So if you have a version without that handler and with your own stuff added, the 301 URL Tracker won't uninstall anymore ;-)
We should get Richard Soeteman here, I think he is one of the Project Admins... Asked him on Twitter (maybe he is on holiday?).
I agree that depending on the PAC dll is an issue that any package developer using it should be aware of.
As you pointed out Matt there is an issue with versions and uninstall. And i'm sure that these kinds of dependencies could potentially break any Umbraco solution.
I usually create install code as part of my own code, and the PAC project is a great source of inspiration for this. And for me it will always be a great source of inspiration, but I would never include it directly in my own package simply because of the potential install and uninstall issues.
As long as there is no way of registering package dependencies in Umbraco I see no other way.
Just my 2 cents
- Morten
There are 2 ways to look at Package Action Contrib:
As suggested, since Package Action Contrib can be overwritten, then the only way to guarantee the uninstall actions to work is compile those package actions directly into your own assemblies.
Don't forget that not all packages use .NET assemblies, so Package Action Contrib is still useful to them.
A compromise would be to have a collection of C# class/scripts that could be included in the App_Code folder. That way each package action is a separate file/script/class.
Cheers, Lee.
@Lee, not a bad idea regarding App_Code, but there is still the potential for it getting overwritten. ie, I've just submitted a patch that adds IIS7 support to the AddHttpHandler. If an older one was installed that replaced my updated one, then again, I wouldn't be able to uninstall completley.
If it was to go that route, I think something would need to be built in to prevent it overwritting newer versions. Not sure how you'd go about that though =)
Matt
Using your AddHttpHandler action as an example Would it break the install? really?
If the old version of AddHttpHandler would add an IIS6-friendly HttpHandler... and your new version added both the IIS6 and IIS7 handlers ... then surely the uninstall/undo would remove both HttpHandler sections? I can't see where it would break the install.
If your new action borks over not being about to find the IIS7 handler, then isn't that down to poor code/logic?
Cheers, Lee.
@Lee
No, the other way around.
He updates the AddHttpHandler. Then another package get's installed with an older version of the AddHttpHandler.
When you uninstall the first package, it won't remove the IIS7 HttpHandler anymore...
This is a tricky one, what are the chances of PAC being a core part of Umbraco ?
Thinking out loud - if including PAC in package, it could be coppied rather than included by the package generator so that it's not included the uninstall process, (would also have to check to ensure it's not replacing a newer version), although only takes one package not to adopt this strategy for it to fail, so not really practical.
@kipusoep: Doh! My bad, misread Matt's example!
@Hendy
It's a bad idea to include it in the Umbraco core, because everybody is modifying and extending it. It's very hard to keep it up-to-date.
I think the best (and maybe only) solution is, to use PAC as example/source and copy everything you need into your own package.
@Lee, yea, as @kipusoep said, it's the other way round that's the problem.
@Hendy, thats the problem. There are a few ways round it, but most are "best practise" so it only takes one dev not to follow it to break packages.
Matt
Only other thing I can think of (which would require some dev, and I'm not even sure is possible) would be to change how PAC works so that when you install a package that uses PAC, it actualy goes and downloads the latest DLL from a trusted source. Obviously this would require everyone who uses it currently to update their packages, but all new ones should work.
Again, I'm not sure how viable an option this is though.
Matt
Anyway Matt what are you worried about? Your packages are so hot - who in their right mind would want to uninstall them? ;-P LOL!
Well, there is that ;) But you still have to cater for those who are clinicaly insane.
Matt
@Matt
If we'd going to use a trusted shared source to keep the assembly centralized, it has to be updated a lot! Say I creat a new Action, how will I get it in the assembly at the trusted shared source? By waiting a few days?
@Kipusoep
I guess that's down to how much resource Rich has =)
Matt
Package dependency is something we discussed at the retreat. No solution came from the chats, but its absolutely worth revisiting.
The example we used was Warren's CWS - as it uses XSLTsearch ... should it use the latest version? How to integrate the dependency? At creation of the package? at install time? (thats risky because it's untested - so then we're looking at specifying stable releases for the dependency)
Hmmm, I think thats probably one for another thread.
Listening to everyone else, it does seem like the best bet is to copy the code to your own package and change the alias name to prevent conflicts.
Unless Rich says otherwise, I reckon this is what I'll be going with.
Cheers guys
Matt
Hi Guys,
Was on a holiday for a few weeks. Great topic with No easy answer. The idea behind the contrib project was to give the user a few extra Actions that they could use without having to compile anything in Visual Studio, A lot of Umbraco devs don't have Visual Studio or a .net development background. When we first started the project nobody implemented the UnInstall option. That's required now btw. Anyway it's a great tool out of the box for installing packages. For Uninstall you can't 100% rely on the dll. Even if we come up with a solution for versioning etc. If the user installs a package with the same PAC dll and Unistall both packages 1 package will uninstall fine, the other will not because the PAC dll is gone. So if you want to be 100% sure (well that is 98% because a lot can go wrong in the Uninstall process) you can include the sourcecode into your own dll.
On the other hand how many people will install a package on a real environment and UnInstall that? I always use a test environment and when I need to have that one cleaned up, I reinstall Umbraco.
Cheers,
Richard
1) You could probably version, compile, and link your own version of the contrib lib and register it in the GAC using the GAC API. Of course this would only work in full trust but that way you could have multiple versions of the same assembly around and with your code linking a specific version you'd get the one you want. We might be talking pure theoretical here though because the hassle is probably too big to actually go ahead and do it..
2) An easier option would be to add an option for overriding the action names and compile your own version of contrib under a different name. With that in place each package can deploy their own version of contrib side by sde and refer to the action by the name + the overriding identifier.
Instead of referring to GrantPermissionForApp you'd refer to GrantPermissionForApp_MyPackge which resides in PackageActionContrib_MyPackage.dll.
Just a couple of ideas.
is working on a reply...