 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Setup / October 2006InstallUtilLib.DLL: Unknown Error?
I'm yet another developer with the useless Installation error message, event viewer is just as useless MsiInstaller error 1001 and shows InstallUtilLib.DLL: Unknown Error, (NULL), (NULL), (NULL) -- oh that is so helpful M$, how could I not know what this means...(yes, google searches has not reveal any solutions, I've tried them all). Trying to install a Windows Service using VS 2005, it will NOT install on any client PC, but will install and work just fine on my development PC (using either the Setup.EXE from Release dir or via the VS IDE right click Install from the setup project. Soon to be ex-developer because my company is about to go under because we fell for the VS 2005 development platform as being ready for prime time -- hope this makes M$ developers, project managers, and QA folks for Windows Installer and VS 2005 feel good -- I guess they have less competition now -- well ya got my $7500 over the past 3 years waiting for VS 2003 successor -- are you happy? WTF is going on with M$? I'm just over it, every freakin' day I'm wasting hours research problems with VS 2005. Any time I try to put a "professional" complete package together with VS 2005, it just doesn't work. I realize that some key people from the VS 2005 dev team were terminated (yes every developer does need some "inside" contacts), but how does that help me here and now? 1. Meaningful error message - how can I proceed without them, needle in a hay stack 2. Don't "release" dev tools that are clearly BETA 3. Firing VS 2005 team members doesn't help me here and now I found a solution, but I have not found the reason for the problem. I uninstalled .NET framework 2.0 on the client PC (my test PC) and let my installer re-install it, this has cured the current issue on my test machine. Why did this happen and how did this happen I will probably never know -- the error message provided by the Install (MSIEXEC) is pathetic at best. I'm going to do more testing because I'd like to duplicate this problem since I've already raised a bug on M$ feedback. I know M$ don't give a rats a.s, but I hope that this might help others that have struggled with this turd of a development platform called VS 2005. Rob. > I'm yet another developer with the useless Installation error message, > event viewer is just as useless MsiInstaller error 1001 and shows [quoted text clipped - 25 lines] > 2. Don't "release" dev tools that are clearly BETA > 3. Firing VS 2005 team members doesn't help me here and now For some reason that I am unaware of, Visual Studio decided to install services in a rather convoluted way. There's a call from the msiexec process to InstallUtilLib.dll passing a bunch of parameters, and then calls on .NET Installer classes that locate your assembly, find its Installer classes, instantiate them, call methods that install the service etc. As you can probably imagine, this is rather complicated and sometimes fragile. However Windows Installer has bult-in support for installing services (the ServiceInstall and ServiceControl tables) that people used for years before .NET came along, so why Visual Studio invented installer classes to install services is a mystery to me. Many installation developers who have been building setups for a while consider managed custom actions a bad thing: http://www.installsite.org/pages/en/msifaq/a/1044.htm I wonder if this is the first time you've built an MSI-based setup. There seem to be a lot of Visual Studio developers doing this since VS setup&deployment projects came along and, although the lack of InstallUtilLib diagnostics is a pain, it's not the only (and probably not even the best) tool for building MSI-based setups. http://www.installsite.org/pages/en/msi/authoring.htm  SignaturePhil Wilson [MVP Windows Installer] ---- >I found a solution, but I have not found the reason for the problem. > [quoted text clipped - 38 lines] >> 2. Don't "release" dev tools that are clearly BETA >> 3. Firing VS 2005 team members doesn't help me here and now Hi Phil, The clue that lead me to think there was more wrong with .NET framework installation was when I tried to uninstall another .NET 2.0 project that had installed just fine a few days ago -- my attempt to remove via Control Panel resulted in the same InstallUtilLib.dll error. The only activity that happened between these states was the uninstall and re-install of .NET 1.1. This seems to have created some problems for .NET 2.0 installer. Fragile is very true. However, I've looked into other tools such as InstallShield and have found that many folks are experiencing the same or similiar problems with InstallUtilLib.dll for their .NET 2.0 projects being distributed via the InstallShield projects. I'm not a dedicated "Installation Developer" -- I'm really the ONLY developer that works on ALL our .NET projects (web, click once, windows services, windows forms, etc.). I've built many MSI setups before. > For some reason that I am unaware of, Visual Studio decided to install > services in a rather convoluted way. There's a call from the msiexec [quoted text clipped - 61 lines] >>> 2. Don't "release" dev tools that are clearly BETA >>> 3. Firing VS 2005 team members doesn't help me here and now It won't matter what tool you buiild an MSI file with if something has broken the InstallUtilLib internals. However you don't need InstallUtilLib to install services, and tools from InstallShield, Wise, Wix etc let you install services using the standard MSI Service table instead of using InstallUtilLib. All I can do is point out that managed custom actions can be fragile, and if you're willing to use another tool to do things like install services, and write custom actions that call a C++ Dll you can completely avoid the fragility of calling managed custom actions. SignaturePhil Wilson [Microsoft MVP-Windows Installer] Definitive Guide to Windows Installer http://apress.com/book/bookDisplay.html?bID=280 > Hi Phil, > [quoted text clipped - 80 lines] >>>> 2. Don't "release" dev tools that are clearly BETA >>>> 3. Firing VS 2005 team members doesn't help me here and now Understand Phil, but I'm trying to stay within the context of VS 2005 and get things done the VS 2005 way (and I'm staying 100% managed). The concept is good, just the implementation is bad, in some cases really bad. That aside, poor error messages that provide no insight is a significant problem with VS 2005, MSI, or just about anything under the M$ umbrella. NULL NULL NULL -- at the very least they could provide the parameter list or what was expected or some clues, NULL can be a clue, but by itself in this context it is completely useless. I've coded several Windows Services now, and my best diagnostics for when problems occur is my extra effort I've put into trapping errors -- especially with multi-threaded processing, sometimes the only way to identify a problem is proper error handling. M$ apparently teach this concept put do not implement it which should concern anyone developing on an M$ platform -- "just enough to meet a deadline" isn't a professional approach and certainly not what I would expect from M$. > It won't matter what tool you buiild an MSI file with if something has > broken the InstallUtilLib internals. However you don't need InstallUtilLib [quoted text clipped - 88 lines] >>>>> 2. Don't "release" dev tools that are clearly BETA >>>>> 3. Firing VS 2005 team members doesn't help me here and now I got this message "installutillib.dll: unknown error" when I tried to install this software "ID Vault" into my system. Can someone tell me what is wrong here? Thanks in advance.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.