I read earlier that someone said that the MSI team issued a `requirement` to
not use managed code. Also to say it's a best practice to not use managed
code is a stretch of the truth also. The future of Windows development is
managed code and I've found very successful ways to incorporate it into my
installs. Anyone who tells me otherwise simply isn't thinking outside of the
box or just likes the torture of writing raw C++ Win32 code.
si <[EMAIL PROTECTED]> wrote:
Hi Bob,
I don't want to get into a religious argument over this, and Dana, yes
I have read about the potential problems, I'm just looking for avenues
to explore to get our development team on the right path. We use C#
for almost everything else, so it's natural for us to want to use this
language if at all possible, especially since Votive works so well in
Visual Studio.
> How would C# make it easier to support uninstall, repair, rollback,
> upgrades, and patching?
I'm not a WiX or windows installer expert, but for what we want to do
with the managed actions; uninstall and rollback would be probably
treated the same i.e. leave everything as it was, likewise for
upgrades and patches. Not sure about repair.
I was actually talking more about leveraging our existing tools for
debugging (e.g. log4net) as well as the tools that ship with .NET i.e.
the Base Class Libraries.
> What are some examples of grunt work?
Sure. One example is our companies custom security and data extensions
for Microsoft Reporting Services. Because this is an existing
product, we can't just overwrite the xml configuration files that
exist with our own versions.
To take the RSSrvPolicy.config as an example, I have nearly 1,000
lines of XmlConfig code in the wxs file related to just 22 xml
elements! This is one of six configuration files we have to modify.
To be fair it's the largest but they all take time to develop and more
importantly, because the idiosyncrasies of XmlConfig are difficult to
develop and debug.
Even Microsoft's own developers have problems with this:
http://blogs.msdn.com/gisenberg/archive/2007/10/09/wix-v3-and-xmlconfig-xmlfile-troubleshooting.aspx
What I'd like is something as simple as the XmlPoke and XmlPeek tasks
that are found in NAnt. We'd also like an XmlBulkAdd action i.e.
adding well-formed elements and attributes instead of having to treat
each element value or attribute invidually. With those actions I
could get my wxs file mentioned above down to less than 100 lines,
making it easier to develop, understand, test and maintain.
We'd also write an XmlTidy action - a few lines of C# thanks to the
BCL - so that the xml files are left in a clean state after being
touched, as anyone who has spent time with XmlFile and XmlConfig
knows, they get messy quickly. Yes, no problem for a parser, but a
pain for humans.
If it's true that a Microsoft supported WiX variant will be in the
next version of Visual Studio, expect a lot more of these sort of
requests from other .NET developers in the not-to-distant future :)
cheers
si
--
It's a wild world that we live in, you step to the vibe like a new
found religion, take your position, compile your vision, futurism,
algorithm has risen up! pfm - the western
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
