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 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.
-------------------------------------------------------------------------
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