Create .msi file from windows installer APIs
sarfu
patches, upgrades, custom actions with Installshield12, wise and inno.
Now for me the requirement is that the .MSI file should be created
from windows installer APIs without any help of any third party
software. I know this can be done, and i have read in SDKs ( Samples
\SysMgmt\Msi ) I guess this section is for experienced persons.
Is there any procedure or step by step tutorial which can create MSI
file from installer APIs??
Thanks and regards
sarfu
Rob Hamflett
creating the entire thing from scratch with just the API?
Rob
Jeff Henkels
MSI's from XML sources.
See http://sourceforge.net/projects/wix.
"sarfu" <biradar...@gmail.com> wrote in message
news:1178618965.0...@h2g2000hsg.googlegroups.com...
sarfu
> Consider using the WiX toolset -- it's an open-source toolset for building
> MSI's from XML sources.
> Seehttp://sourceforge.net/projects/wix.
>
>
> news:1178618965.0...@h2g2000hsg.googlegroups.com...
>
>
>
> > Hi i have little experience of creating .msi/setup files, creating
> > patches, upgrades, custom actions with Installshield12, wise and inno.
>
> > Now for me the requirement is that the .MSI file should be created
> > from windows installer APIs without any help of any third party
> > software. I know this can be done, and i have read in SDKs ( Samples
> > \SysMgmt\Msi ) I guess this section is for experienced persons.
>
> > Is there any procedure or step by step tutorial which can create MSI
> > file from installer APIs??
>
> > Thanks and regards
>
> - Show quoted text -
Thanks Rob and Jeff
I can understand your concern ( Why would you want to do this?). I
know wix and used it and created setups using it.
But what i/we do by using wix is just including some binary files and
run with candle and light.
I want to under stand what really happens inside ( what action gets
called.. etc) when we build setup file and the requirement is like
that ( i cant mention it here).
I think i have to start with Orca and SDK but really don't know how.
Your Inputs will do lot.
Thanks
Sarfu
Stefan Krueger [MVP]
can see exactly which APIs are being called.
--
Stefan Krueger
Microsoft Windows Installer MVP
Please post your questions in the newsgroup or vist one of these web sites:
Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de
InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)
"sarfu" <biradar...@gmail.com> schrieb im Newsbeitrag
news:1178631676.4...@u30g2000hsc.googlegroups.com...
mayayana
> I want to under stand what really happens inside ( what action gets
> called.. etc) when we build setup file and the requirement is like
> that ( i cant mention it here).
>
> I think i have to start with Orca and SDK but really don't know how.
>
The CHM help file in the SDK is very good. Pretty
much everything is covered in there, but it's extremely
complex. Microsoft has gone to great lengths to ensure
that MSIs are not easy to build. Whether you want to
write something like a scripted HTA or a compiled EXE,
you'll need to get into some very complex code in order
to provide yourself with basic GUI functionality to do things
like adding files to the package or designing dialogues.
As an alternative to the Wix source code, you *can*
actually do the whole thing as simple script in HTAs if
you want to. MSI has a full automation interface. See
here for VBScript code:
http://www.jsware.net/jsware/msicode.php3
There are also a large number of script samples in
the SDK.
Dennis Bareis
>
>Thanks Rob and Jeff
>I can understand your concern ( Why would you want to do this?). I
>know wix and used it and created setups using it.
>But what i/we do by using wix is just including some binary files and
>run with candle and light.
>
>I want to under stand what really happens inside ( what action gets
>called.. etc) when we build setup file and the requirement is like
>that ( i cant mention it here).
>
>I think i have to start with Orca and SDK but really don't know how.
You might want to try MAKEMSI instead of orca as you can do exactly
the same table/row manipulation but easier. Its as close to the "API"
as you can get...
Bye,
Dennis
Dennis Bareis [Microsoft MVP] (dba...@KillSpam.gmail.com)
http://dennisbareis.com/
Freeware Windows Installer creation tool (+ "ORCA automation"):
http://makemsi.dennisbareis.com/
sarfu
Thanks Stefan and Maya
It seems its difficult and also not worth trying with APIs.
But I would like to explore it just for understanding purpose. Maya as
you said ( The CHM help file in the SDK is very good)
can u tell me which CHM file you are referring? Sorry to say i failed
to
notice this CHM in SDK ( I am using Microsoft Platform SDK for Windows
Server 2003 R2) which SDK you are referring?
Or i may be looking at different ( may be Higher than 2003) Can u
please tell me which SDK and path for CHM?
Thanks
Sam Hobbs
but of course the hard part is filling it with all the tables with proper
internal references.
Sub CreateDatabase(Name)
Wscript.Echo "Creating: " + Name
Dim Installer, Database, Table
Set Installer = Wscript.CreateObject("WindowsInstaller.Installer")
Set Database = Installer.OpenDatabase(Name, msiOpenDatabaseModeCreate)
Database.Commit
End Sub
"sarfu" <biradar...@gmail.com> wrote in message
news:1178618965.0...@h2g2000hsg.googlegroups.com...
mayayana
> to
> notice this CHM in SDK ( I am using Microsoft Platform SDK for Windows
> Server 2003 R2) which SDK you are referring?
I meant the MSI (Windows Installer) SDK. There's an
msi.chm in that, as well as a number of sample VBS
files. As far as I know there is only a v. 1.1 of the download,
but MSI seems to have changed in only very minor ways
since then, despite the numerous major version
changes.
I don't have a link offhand, but you can download
the Windows Installer SDK separately from the general
SDK. The CHM file documents the multitude of tables
very clearly. So it's possible, with some work and a lot of
brow wrinkling, to work out the structure of an MSI.
People seem to think Wix is useful. Maybe I'm missing
something, but to my mind the MSI system is already so
overly complex as to be absurd. Wix seems to just wrap
that in XML, as a way of creating a structured method to
build an MSI. While XML may be the height of fashion,
it's also very tedious to work with. I'm guessing that Wix
might be a practical joke perpetrated by MS, as in, "Hey,
they went for that MSI stuff. Let's see if they'll go for this!
That would be so funny!" :)
Stefan Krueger [MVP]
download as a separate .chm file but is part of the Platform SDK
documentation. You can find links for download and online viewing at
http://www.msifaq.com/a/1005.htm
Some Windows Installert tools include the Windows Istaller documentation as
.chm file however. And you can create an offline copy yourself:
http://msmvps.com/blogs/installsite/archive/2007/05/05/891084.aspx
--
Stefan Krueger
Microsoft Windows Installer MVP
Please post your questions in the newsgroup or vist one of these web sites:
Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de
InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)
"mayayana" <mayaXX...@mindXXspring.com> schrieb im Newsbeitrag
news:rgk0i.5244$296....@newsread4.news.pas.earthlink.net...
Richard [Microsoft Windows Installer MVP]
"mayayana" <mayaXX...@mindXXspring.com> spake the secret code
<Gn00i.9128$j63....@newsread2.news.pas.earthlink.net> thusly:
> The CHM help file in the SDK is very good. Pretty
>much everything is covered in there, but it's extremely
>complex. Microsoft has gone to great lengths to ensure
>that MSIs are not easy to build.
Oh come on. MSI is not *intentionally* made any more complex than it
has to be.
The bottom line is that a fully general tool for meeting all the needs
of application installation *and* the feature sets of MSI (resiliency,
run from source, repair, etc.) is why MSI has all the bells and
whistles that it has.
A lot of people say MSI is complicated simply because they don't
understand the basic concept of declaring everything in a database and
asking the runtime engine to do all the work.
For the original poster:
The SDK has walkthroughs for installing a basic Notepad like program
and its not very hard to do with Orca. Start with that.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
mayayana
> download as a separate .chm file but is part of the Platform SDK
> documentation.
Actually I wasn't thinking of either of those. There's a
Windows Installer SDK here:
http://www.microsoft.com/downloads/thankyou.aspx?familyId=e96f8abc-62c3-4cc3
-93ad-bfc98e3ae4a3&displayLang=en
http://download.microsoft.com/download/platformsdk/wininst/1.1/WIN98/EN-US/I
ntelSDK.msi
The download has the msi.chm file in it. There may be
newer info. in the full SDK. I don't know. But for anyone who
doesn't want to, or can't, deal with the whole thing, the
MSI SDK is only about 8 MB.
mayayana
> Oh come on. MSI is not *intentionally* made any more complex than it
> has to be.
>
"Oh come on"? You may find it hard to believe, but I think a
few people may disagree with your assessment. I certainly do.
Microsoft has created an entire system just to install software.
And it's not small. Yet building an installer with that system entails
more work than writing a lot of software does. The average
programmer can't grasp it. Most of them use InstallShield or Wise.
And why would they want to grasp it? The point is to install their
software, not to learn a whole new programming system.
And there are no tools. With all of that work MS couldn't provide
some kind of decent GUI to automate MSI building and dialogue
creation? Orca is a very basic, primitive tool that only provides the
most basic access to the database.
>
> A lot of people say MSI is complicated simply because they don't
> understand the basic concept of declaring everything in a database and
> asking the runtime engine to do all the work.
>
Exactly. The runtime does all the work. Yet it requires 80-odd
heavily-cross-referenced tables (and often extra "custom actions"
...and in the case of InstallShield, another set of binaries within the
database...) just to tell that runtime how to show a few dialogues,
copy a few files, and create some Registry entries. It's hard
for me to imagine how anyone could think that makes sense.
So that's why I said it's intentionally complex. I can only assume
that either 1) MS was afraid of stepping on the toes of InstallShield
and getting sued, or 2) the people at InstallShield are MS insiders.
Personally I can't imagine why anyone uses Windows Installer,
with other dependable, inexpensive and reasonable options available.
I'm assuming that the people here are generally working in large
corporate environments and have been given no choice but
to use Microsoft's "official" methods.
But I piped up because the OP seems to want to get to the
bottom of it all. And if I were ever to seriously consider using
Windows Installer to actually install software then that's probably
what I'd do: Build myself some kind of easier GUI interface to do
the work and hide the horrendous organization of the MSI
database, rather than slog through Orca, XML in Notepoad, etc.
for every installation build.
Richard [Microsoft Windows Installer MVP]
"mayayana" <mayaXX...@mindXXspring.com> spake the secret code
<Tjp0i.9470$j63...@newsread2.news.pas.earthlink.net> thusly:
>> Oh come on. MSI is not *intentionally* made any more complex than it
>> has to be.
>>
>
> "Oh come on"? You may find it hard to believe, but I think a
>few people may disagree with your assessment. I certainly do.
You have an opinion, but that doesn't make it a fact.
Christopher Painter
that it is both overly complicated AND fails to meet the needs of all
application installation stories. I continue to use it because it is
still the best sdk out there and I know how important it is in large
corporate environments where silent bulletproof deployment automation
is king. That reason alone is enough for me to put up with MSI.
However, I think those who defend it's broken and/or missing patterns
with circular logic, dogmatic thinking and arrogant boasts of
superiority ( their own or their tool's ) fail to help the community
has a whole. I think we'd be better served in trying to push MSI to
new levels then defend the status quo and attack all those who
challenge.
Sam Hobbs
seems to happen. Seriously speaking, the problem is that Microsoft has
developed a lot of software without thinking about what they are doing. The
Windows Installer is the result of many years of design by need. It was not
designed from the beginning to do all that it does; many of the current
requirements were not imagined originally. It just happened more than it was
designed.
If Microsoft were familiar with common System Design methodology, they would
analyze the Windows Installer to determine requirements independent of the
solution, then design a system to satisfy those requirements. They would end
up with a radically different system. Yet Microsoft does things the old way
of developing software that satisfies limited views and then attempting to
enhance it to satisfy the wider view. That creates software that is a
cumbersome kludge.
"Richard [Microsoft Windows Installer MVP]"
<legaliz...@mail.xmission.com> wrote in message
news:OMz3hEm...@TK2MSFTNGP06.phx.gbl...
Richard [Microsoft Windows Installer MVP]
"Sam Hobbs" <sam...@social.rr.com_change_social_to_socal> spake the secret code
<O0962Zpk...@TK2MSFTNGP02.phx.gbl> thusly:
>Microsoft certainly creates terminology to confuse. Or at least that is what
>seems to happen. Seriously speaking, the problem is that Microsoft has
>developed a lot of software without thinking about what they are doing.
Based on what? I have talked with the engineers that work on the MSI
code and I can certainly tell you that they think about what they are
doing.
>The
>Windows Installer is the result of many years of design by need. It was not
>designed from the beginning to do all that it does; many of the current
>requirements were not imagined originally. It just happened more than it was
>designed.
There is no crystal ball for software that lets you design today what
you will need tomorrow. *Noone* writes software that way. Noone ever
did.
>If Microsoft were familiar with common System Design methodology, they would
>analyze the Windows Installer to determine requirements independent of the
>solution, then design a system to satisfy those requirements. They would end
>up with a radically different system. Yet Microsoft does things the old way
>of developing software that satisfies limited views and then attempting to
>enhance it to satisfy the wider view. That creates software that is a
>cumbersome kludge.
I disagree. What you describe, according to the most appropriate
definition I can find in Wikipedia:
<http://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Methodology_%28SSADM%29>
is a "waterfall" design methodology, which the entire software
industry has pretty much moved away from in favor of agile development
methodology. At my current employer, they used to do waterfall and
now we do agile. In the past it took years to get out a release and
customers weren't happy with the functionality. Now we add so much
targetted customer value and release so quickly that customers have
actually started to ask us to slow down our release cycles because
they don't have time to incorporate all the new functionality into
their processes. I think that about says it all for agile vs.
waterfall, but its an argument that continues in software engineering
circles. Having done both personally, I *never* want to do waterfall
style development again. Its not only expensive, but it is not
personally rewarding.
Sam Hobbs
> [Please do not mail me a copy of your followup]
>
> you will need tomorrow. *Noone* writes software that way. Noone ever
> did.
They definitely do, however that is not what I said. I said that Microsoft
should analyze what currently exists. In other words, current requirements
are totally clear.
What Microsoft could have done and should have done is to make an attempt to
foresee requirements and design the installer software to satisfy
requirements better.
If you want to discuss this further, then we can create a thread in the
(non-Microsoft) system design newsgroup to get discussion that includes
experts.
> I disagree. What you describe, according to the most appropriate
> definition I can find in Wikipedia:
> <http://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Methodology_%28SSADM%29>
> is a "waterfall" design methodology, which the entire software
> industry has pretty much moved away from in favor of agile development
> methodology. At my current employer, they used to do waterfall and
> now we do agile. In the past it took years to get out a release and
> customers weren't happy with the functionality. Now we add so much
> targetted customer value and release so quickly that customers have
> actually started to ask us to slow down our release cycles because
> they don't have time to incorporate all the new functionality into
> their processes. I think that about says it all for agile vs.
> waterfall, but its an argument that continues in software engineering
> circles. Having done both personally, I *never* want to do waterfall
> style development again. Its not only expensive, but it is not
> personally rewarding.
System design methodolgy was very well established over a quarter century
ago. There are hundreds of books, probably thousands. There are probably
hundreds of methodologies. One critical issue is requirements definition
(although it might be called something else) and an important point is that
a little (relative) time spent defining requirements can save enormous time
later. In the case of the Windows Installer, that is extremely true. A
better designed Windows Installer can save much time of much software.
I know that many software managers want projects done as quickly as possible
and if they don't allow enough time in the beginning (requirements
definition and system analysis/design) then they are spending excessive
amounts for software development.
zdvso...@hotmail.com
authoring. I can also ensure you that Microsoft did not try to ease
Setup authoring.
In fact Microsoft listened to somebody else: administrators. Read
about it here: http://www.microsoft.com/windows2000/docs/wininstaller.doc
>Personally I can't imagine why anyone uses Windows Installer,
>with other dependable, inexpensive and reasonable options available.
I can give you a reason why most of us use Windows Installer: The
customer asks to do so. If you don't have such customers, stay away.
In my case a customer asked my company how to install my software at
40,000 end users. That was 1999 and I didn't have an answer, and the
deal did no go through.
>I'm assuming that the people here are generally working in large
>corporate environments and have been given no choice but
>to use Microsoft's "official" methods.
Actually I've worked for ISVs. In ISVs it works like this: we are
given no choice but to listen to the customers. And yes, some want
Windows Installer.
mayayana
> authoring. I can also ensure you that Microsoft did not try to ease
> Setup authoring.
Well, I suppose it's possible that they didn't even try
to make a mess of it. I'm giving them the benefit of
the doubt. :)
> >Personally I can't imagine why anyone uses Windows Installer,
> >with other dependable, inexpensive and reasonable options available.
>
> I can give you a reason why most of us use Windows Installer: The
> customer asks to do so. If you don't have such customers, stay away.
Unfortunately, MS is not making that easy. W.I. serves,
among other things, as a way to exert a finer control
over 3rd-party Windows software. I originally encountered
W.I. because I was writing some little utilities for a blind
friend, a few years back, and wanted to install SAPI 5 on
his system. It turned out that the only way to get the 5+- MB
of SAPI 5 runtimes that I needed was to download 100 MB
of MSMs and write an MSI installer! I ended up writing an
MSI/MSM disassembler instead. It seemed much easier.
I see what you mean, though, in terms of large-scale
corporate installations. And I can see that MSI has some
strengths in that scenario.
Stefan Krueger [MVP]
Installer itself as well as documentation improvements.
--
Stefan Krueger
Microsoft Windows Installer MVP
Please post your questions in the newsgroup or vist one of these web sites:
Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de
InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)
"mayayana" <mayaXX...@mindXXspring.com> schrieb im Newsbeitrag
news:sQo0i.13590$3P3....@newsread3.news.pas.earthlink.net...
Stefan Krueger [MVP]
Installer selbst als auch Verbeserungen und Ergänzungen in der
Dokumentation.
--
Stefan Krueger
Microsoft Windows Installer MVP
Please post your questions in the newsgroup or vist one of these web sites:
Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de
InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)
"mayayana" <mayaXX...@mindXXspring.com> schrieb im Newsbeitrag
news:sQo0i.13590$3P3....@newsread3.news.pas.earthlink.net...
PLohrman
consistently for about 3 months to get the functionality up to the point of
being able to incorporate the majority of features we needed. I've been
working for another 3 months on-and-off to fine tune the behavior and add
customizations to the installations.
A good portion of that time was spent reading and understanding the database
tables: http://msdn2.microsoft.com/en-us/library/aa368259.aspx and the
installer object interface:
http://msdn2.microsoft.com/en-us/library/aa369432.aspx
I didn't hear about WiX until afterwards and haven't used it, but it
probably would have been wise to look at that first and then thought about
building on its functionality.
Sam Hobbs
am not the one asking for help. Note also that by definition of the problem
WiX cannot be used; it has already been suggested as a sample.
"PLohrman" <PLoh...@discussions.microsoft.com> wrote in message
news:B450CBC0-0058-4580...@microsoft.com...