One thing to be careful with is pointing to things in "any Microsoft platform" and saying "Well, Microsoft created this platform so it must be a good pattern." InstallUtil is not a good thing (for the reasons I pointed to in the SelfReg table documentation) and it still exists for backwards compatibility reasons.
It appears you are optimizing for code reuse whichis generally a good thing. However, again, I would be wary of trying to optimize ~20 lines of code and doing bad things to your installation. There are things that could be improved (for example harvesting service information out of assemblies much the way heat can do that for CLR COM goo) but we're not there yet. Forcing solutions that have shown to have bad experiences in the large seems wrong to me (I pull a lot of my experience from shipping a couple versions of Microsoft Office and a Windows relesae [plus a few other products that can only be described as "smaller" <wink/>]). But it is your product. If what you have works better for your solution, cool. Best of luck with it! <smile/> On Mon, Feb 14, 2011 at 5:44 AM, Rune Moberg <jjfl...@gmail.com> wrote: > On Mon, Feb 14, 2011 at 1:10 PM, Christopher Painter > <chr...@deploymentengineering.com> wrote: > > For #4, you are right, it is simple. I can do it in one line of XML in > WiX and > > let MSI handle the details. For developers I can do it in 1 line of .BAT > using > > the SC command. And, no, your InstallUtil code will not be better. > > Using batch files, adding yet another way of registering your > services? Which is exactly the solution I'm replacing. Why not use > srvany.exe while you're at it..? > > Code duplication is frowned upon. Having service registration > information residing in batch files means you've done just that. Not > to mention that admins familiar with the '-i' command line switch have > to deal with your services in yet a different way. > > Cristopher, I am not saying that "my" solution is the optimal. What I > am saying is that <ServiceInstall> does not fully satisfy the KISS > principle. Adding batchfiles to handle the other cases is a big clue > as to why it isn't satisfactory. Some improvements here would be most > helpful, at least to me! > > It is useful with a unified way of registering an executable as a > service. _Currently_, the .Net platform offers the Installer > framework. It has its downsides as you point out, but... It is still > the lesser of the evils presented so far! A more metainfo-based > replacement could perhaps solve the remaining issues? > > -- > Rune > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
