Sure, MSI should have the ability to combine complete MSI installation
packages as phases of the installation, together with the transactional
behaviour (including savepoints on the registry..)... is this
something related to staged installation & Windows Installer 4.5?
Otherwise there might be several reasons for the lack of this feature, I
know... would this have effects on security which make it better to forget
about the whole misery? perhaps backward compatibility makes it impossible?
or too much ado for something that can be avoided with "hacks"?
2007/11/15, Christopher Painter <[EMAIL PROTECTED]>:
>
> Why not blame MSI? Sure they are dependant on Fusion, but why did they
> make the choice to wait to the commit phase to call fusion? The stated
> reason is to provide rollback capabilities but the problem I have with that
> is GAC is SN ... while rollback is nice to have, the risk of system
> instability should be next to none due to the very nature of GAC/SN. So I
> have an extra assembly in storage or I have an assembly with a higher
> AssemblyFileVersion. That should not be the end of the world but if they
> are still worried about it, they really, really should have found some way
> to be true to the transacted nature and execution phases so that this type
> of problem was mitigated.
>
> And adding the CRT as a static link for C++ developers only solves some
> problems. It wouldn't solve my problems. I work .NET SOA SaaS installs
> and without getting into all the details I have about a dozen application
> framework blocks that have to be deployed to the GAC for consumption across
> WebUI, WebServices ( 80+ ) and WindowsServices.
>
> The ASP.NET <http://asp.net/> is fine because the assemblies won't be
> needed until the sites are accessed and the content JIT'd. But the
> WindowsServices need the files ( it's basically a client that consumes the
> web services )
>
> The customer pays the bills and they say 1) don't copy the assemblies
> local 2) start the service right away 3) avoid a reboot. So while I
> could argue to change the code to break the dependency on the GAC, it ain't
> going to be happening.
>
>
>
>
> *Rob Mensching <[EMAIL PROTECTED]>* wrote:
>
> I don't know where to reply to this thread so I thought I'd just start
> here.
>
> Personally, in the list of all the technologies to blame, I blame
> Fusion.
>
> Fusion is the technology under the GAC (Fusion is actually a code name
> for a few things but the GAC is very much Fusion's fault) and due to
> some (IMHO) really brain dead design decisions they created a system
> that doesn't interact really well with existing installation
> technologies. Then the C++ team did another brain dead thing (IMHO) and
> took a dependency on Fusion and made the C Run Time (CRT) Win32 SxS
> DLLs. Now we have deep, low-level, core functionality that pretty much
> everyone on the planet (that writes C++) needs dependent on a high
> level, poorly designed, data store (aka: GAC).
>
> The easiest way out of the mess and the one that I always recommend is
> to statically link the CRT. There are downsides (your executable is
> bigger for example) but your install gets so amazingly more simple that
> I personally can't imagine making the trade off the other way.
>
> For example, you'll notice all of the WiX custom actions statically link
> to the CRT so your install has no dependencies on the GAC (which are
> actually impossible to satisfy in the middle of an install).
>
> PS: Has anyone ever noticed how many custom actions the CRT merge
> modules pull in? Terrifying amounts of code to do something that should
> have remained simple, copy the CRT with your application. And to think,
> people use to argue that the GAC was going to make installation easier.
>
>
>
> Adam Majer wrote:
> > Richard wrote:
> >
> >> The problem isn't anything to do with Vista, its because your service
> >> has a dependency on something in the GAC and the files don't really
> >> appear in the GAC until after the Commit phase of the install.
> >>
> >> Just mark your service as starting automaticly and you shouldn't have
> >> any problem. Then Windows will start the service when its needed.
> >> Why do you think that you must start your service before the install
> >> finishes?
> >>
> >
> > First a general comment - thanks for all the replies!
> >
> > Regarding the service now, I think the problem has a lot to do with the
> > installation of stuff into the GAC (the recommended way of doing things
> > after all). All that the service needs is the C runtime, nothing special
> > here. But that is not available.
> >
> > Now, wix has
> >
> >
> >
> > so, why have that? Coincidently, it works on *every* release of windows,
> > but not Vista because of Vista's new way of handing assemblies.
> > Therefore the bug is either in WiX, Windows Installer or Vista. By my
> > understanding of how things work, GAC
> > refresh/update/install/committing/whatever you want to call it, should
> > just be an API call within Windows Installer so the installation
> > sequence can be,
> >
> >
> > .. install stuff (including to GAC)
> > .. refresh GAC -- maybe this could be a custom step that doesn't run
> > unless needed, like when starting services before installation is done.
> > .. start services.
> >
> > Then if start services fails, you roll back by uninstalling the stuff
> > from the GAC, (refreshing it again, if you have done it before) and
> > rolling back the rest of the installation.
> >
> >
> > Finally, the application here is installed as a service because it is
> > not a user intractable application and it is the easiest way of doing
> > things. But yes, there may be another way of running it... messy, but
> > possible. But for general case, does windows have triggers that allow a
> > service to be started automatically when someone tried to connect to UDP
> > port 123 (example) or a named pipe? If yes, then I guess
> > ServiceControl's start attribute can be removed?
> >
> > - Adam
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ------------------------------
> Never miss a thing. Make Yahoo your
> homepage.<http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
