Pretty funny stuff! Sad but true...

Ah, okay. Well, I think most of my critical woes are gone now. I was trying to register assemblies in a custom action, and that was a bad idea, so I let the MSI handle the registration. I still notice that the MSI doesn't seem to delete some registry entries that it added, and perhaps sometimes the Uninstall custom action isn't called, but that's more of a matter of tidying up the registry than something critical. (I try to clean up the Registry after myself, but it's not my fault if the MSI sometimes can't be bothered to do it.) Thanks! Arun

Do you think our deployment projects have anything in common besides the obvious (.NET, etc.)? Is there some way we could work together on solving this?

Thanks for your reply! I have been looking at the full log file off and on for several months, and I don't see anything in there explaining my problems, especially why the Uninstall custom action sometimes doesn't run.

If you call TcpClient.GetStream(), you also need to close the Stream in addition to the TcpClient.

I'm having some inconsistency problems with my deployment project ("Setup") and its custom actions ("Installer"). I'm using Visual Studio .NET 2003 (.NET 1.1, no service pack) on Windows XPSP1. My main project is a band object (Explorer Bar) in an assembly (.DLL) that needs to be registered on installation and unregisted on uninstallation. In addition, during installation, Setup creates registry subkeys, sets registry values, installs some application files, and adds a new file-type. On uninstallation, Setup is supposed to undo all of that. More specifically, I have custom actions for Setup that are run within the Installer class. The Installer class is within the main assembly, and perhaps surprisingly, that seems to work, some of the time. I have also tried putting the Installer class in its own assembly, both as a class library and as a console application, and that doesn't seem to work any better than having the Installer class in the main assembly. Sometimes the registration or unregistration of the main assembly fails. The workaround we tell our users (a small userbase so far, fortunately) is to "repair" after installation, or to uninstall completely before installing a new version. Neither are as ideal as being able to simply install over the previous version. I think there are two subproblems. 1) The Uninstall custom action in the Installer class isn't always called. This is especially inconsistent. My Installer class overrides OnBeforeUninstall() [so that the main assembly is unregistered before the files are removed] and Uninstall() [so that savedState is empty, in order for the installState to be removed]. Lacking better debugging tools for MSIs, I added code in these methods to set registry entries containing the timestamp at the beginning and end of each of these methods. I verified that usually the Uninstall custom action is (but not always) called when the user explicitly asks to remove the package (via "Add/Remove Programs"), but when the user is installing over a previous version, sometimes (but not always) the Uninstall custom action is called. As a side note, I change the installer version, PackageCode, and ProductCode whenever I build a new installer. I don't understand why these inconsistencies occur. For a while I thought VS.NET might randomly corrupt the Setup.vdproj file and that I'd have to remove and add the custom actions again, in order to be sure that the Uninstall custom action was registered, and once or twice I built the Setup.vdproj file from scratch,

I'm having some inconsistency problems with my deployment project ("Setup") and its custom actions ("Installer"). I'm using Visual Studio .NET 2003 (.NET 1.1, no service pack) on Windows XPSP1. My main project is a band object (Explorer Bar) in an assembly (.DLL) that needs to be registered on installation and unregisted on uninstallation. In addition, during installation, Setup creates registry subkeys, sets registry values, installs some application files, and adds a new file-type. On uninstallation, Setup is supposed to undo all of that. More specifically, I have custom actions for Setup that are run within the Installer class. The Installer class is within the main assembly, and perhaps surprisingly, that seems to work, some of the time. I have also tried putting the Installer class in its own assembly, both as a class library and as a console application, and that doesn't seem to work any better than having the Installer class in the main assembly. Sometimes the registration or unregistration of the main assembly fails. The workaround we tell our users (a small userbase so far, fortunately) is to "repair" after installation, or to uninstall completely before installing a new version. Neither are as ideal as being able to simply install over the previous version. I think there are two subproblems. 1) The Uninstall custom action in the Installer class isn't always called. This is especially inconsistent. My Installer class overrides OnBeforeUninstall() [so that the main assembly is unregistered before the files are removed] and Uninstall() [so that savedState is empty, in order for the installState to be removed]. Lacking better debugging tools for MSIs, I added code in these methods to set registry entries containing the timestamp at the beginning and end of each of these methods. I verified that usually the Uninstall custom action is (but not always) called when the user explicitly asks to remove the package (via "Add/Remove Programs"), but when the user is installing over a previous version, sometimes (but not always) the Uninstall custom action is called. As a side note, I change the installer version, PackageCode, and ProductCode whenever I build a new installer. I don't understand why these inconsistencies occur. For a while I thought VS.NET might randomly corrupt the Setup.vdproj file and that I'd have to remove and add the custom actions again, in order to be sure that the Uninstall custom action was registered, and once or twice I built the Setup.vdproj file from scratch,

I'm having some inconsistency problems with my deployment project ("Setup") and its custom actions ("Installer"). I'm using Visual Studio .NET 2003 (.NET 1.1, no service pack) on Windows XPSP1. My main project is a band object (Explorer Bar) in an assembly (.DLL) that needs to be registered on installation and unregisted on uninstallation. In addition, during installation, Setup creates registry subkeys, sets registry values, installs some application files, and adds a new file-type. On uninstallation, Setup is supposed to undo all of that. More specifically, I have custom actions for Setup that are run within the Installer class. The Installer class is within the main assembly, and perhaps surprisingly, that seems to work, some of the time. I have also tried putting the Installer class in its own assembly, both as a class library and as a console application, and that doesn't seem to work any better than having the Installer class in the main assembly. Sometimes the registration or unregistration of the main assembly fails. The workaround we tell our users (a small userbase so far, fortunately) is to "repair" after installation, or to uninstall completely before installing a new version. Neither are as ideal as being able to simply install over the previous version. I think there are two subproblems. 1) The Uninstall custom action in the Installer class isn't always called. This is especially inconsistent. My Installer class overrides OnBeforeUninstall() [so that the main assembly is unregistered before the files are removed] and Uninstall() [so that savedState is empty, in order for the installState to be removed]. Lacking better debugging tools for MSIs, I added code in these methods to set registry entries containing the timestamp at the beginning and end of each of these methods. I verified that usually the Uninstall custom action is (but not always) called when the user explicitly asks to remove the package (via "Add/Remove Programs"), but when the user is installing over a previous version, sometimes (but not always) the Uninstall custom action is called. As a side note, I change the installer version, PackageCode, and ProductCode whenever I build a new installer. I don't understand why these inconsistencies occur. For a while I thought VS.NET might randomly corrupt the Setup.vdproj file and that I'd have to remove and add the custom actions again, in order to be sure that the Uninstall custom action was registered, and once or twice I built the Setup.vdproj file from scratch,

I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My application is using the Windows Installer Bootstrap. (I may have also installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly Support.) I have a few issues and questions regarding the MSI and its properties. * This may be my biggest annoyance at the moment. When the installer creates the target directory, it's setting them as read-only. When the application is uninstalled, the target directory is not deleted, although it's empty. I presume this is because the target directory is read-only and the installer doesn't try to force the removal, but I'm not positive. Why is this happening, anyway, and how can I correct it. I'm not certain if this has always been a problem for me with this project, but it's also not a recently new problem. * When the user opts to install for "Everyone," I need to modify the registry for all users. I'm not sure there's a reasonable way to do this within VS.NET's IDE (or otherwise?). The User/Machine Hive is an alias for HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems useful (ever) for setting within the .DEFAULT tree, but that doesn't handle current users. I've seen a reference to HKEY_PER_USER, which seems like what I'd want, but I don't know how to access it, and there's almost zero documentation online, so maybe it's vaporware. I suppose I could handle this programmatically, in a custom action, but it seems like a common enough need, and I'd rather have the installer handle as much as possible, anyhow! Plus, how can the custom action know that it's supposed to set keys for all users? Can the custom actions access the MSI's runtime properties? * For that matter, I'm not sure there's a good way for users' configurations to be retained during an upgrade, and possibly my real problem here is that I have RemovePreviousVersions set to True. But if an installer is supposed to remove its files and registry keys it created, and if the installer is supposed to first uninstall previous versions (which makes sense in my case), then how are previous configurations supposed to migrate forward? * There doesn't seem to be a good way for defining deployment projects in terms of solution configurations. For instance, I can configure the project within a certain solution configuration (e.g. Debug) to add some conditional compilation constants (e.g. TRACE, DEBUG), and I can use those constants in my code within #if blocks. How can I do something similar within a deployment pro

I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My application is using the Windows Installer Bootstrap. (I may have also installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly Support.) I have a few issues and questions regarding the MSI and its properties. * This may be my biggest annoyance at the moment. When the installer creates the target directory, it's setting them as read-only. When the application is uninstalled, the target directory is not deleted, although it's empty. I presume this is because the target directory is read-only and the installer doesn't try to force the removal, but I'm not positive. Why is this happening, anyway, and how can I correct it. I'm not certain if this has always been a problem for me with this project, but it's also not a recently new problem. * When the user opts to install for "Everyone," I need to modify the registry for all users. I'm not sure there's a reasonable way to do this within VS.NET's IDE (or otherwise?). The User/Machine Hive is an alias for HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems useful (ever) for setting within the .DEFAULT tree, but that doesn't handle current users. I've seen a reference to HKEY_PER_USER, which seems like what I'd want, but I don't know how to access it, and there's almost zero documentation online, so maybe it's vaporware. I suppose I could handle this programmatically, in a custom action, but it seems like a common enough need, and I'd rather have the installer handle as much as possible, anyhow! Plus, how can the custom action know that it's supposed to set keys for all users? Can the custom actions access the MSI's runtime properties? * For that matter, I'm not sure there's a good way for users' configurations to be retained during an upgrade, and possibly my real problem here is that I have RemovePreviousVersions set to True. But if an installer is supposed to remove its files and registry keys it created, and if the installer is supposed to first uninstall previous versions (which makes sense in my case), then how are previous configurations supposed to migrate forward? * There doesn't seem to be a good way for defining deployment projects in terms of solution configurations. For instance, I can configure the project within a certain solution configuration (e.g. Debug) to add some conditional compilation constants (e.g. TRACE, DEBUG), and I can use those constants in my code within #if blocks. How can I do something similar within

I have a .NET EXE, and I have a .NET DLL, which is running as an Explorer Bar (under IE). I'd like to call a method in the active Explorer Bar in order to pass data from the EXE to the Explorer Bar. They are both running on the same computer, but in different processes. It would seem like this is a task for .NET remoting, but I don't really want to establish a channel for each Explorer Bar, and besides, this aspect isn't critical. So it seems that maybe this task is better suited for COM? Can someone confirm or reject this? I thought .NET was going to kill COM, but in this case, it seems that COM is more appropriate than .NET remoting. Thanks, Arun

The project I'm developing is an Explorer bar which loads and saves files. Because it's an Explorer bar, the target output is a DLL (C# assembly). When the saved files are double-clicked, I would like to launch the Explorer bar. Is it possible to setup an open handler within the DLL, rather than writing a helper EXE that will launch the Explorer bar, etc.? I like the idea of keeping the open-file handler bundled with the Explorer bar in the same DLL. In the mean time, until I hear from someone, I'll work on a helper EXE. Thanks! Arun

Is your application multithreaded? It could be that your code is not actually thread-safe, but you haven't actually tested it enough on uniprocessor machines to see it fail.

That should work! I use very similar code in a custom XML serializer/deserializer I wrote. This also works: MessageBox.Show(((int)Enum.Parse(typeof(AnchorStyles), "Left")).ToString()); It displays "4". Maybe enumObject is returning null, perhaps because the enumString is incorrect?

I'm in a somewhat sticky situation. I'm developing an Explorer Bar (for IE). In my implementation, I used a few singletons for very important (core) classes which are, by design, singleton. I guess I didn't want to have to manage parent-child relations for conceivably every object I worked with, but it seems like that was a bad decision. This worked okay until I realized that new windows in IE (such as created by Ctrl-N or File->New Window) are running in the same process, and since the singleton pattern I'm using does so with a static accessor (get) property, this system fails as I believe the two instances of the Explorer Bar are running in the same AppDomain because they're running in two different threads of the same IE process. So basically, instead of having separate singletons per thread group, then end up sharing the same singleton, which is bad for Windows Forms objects. :) The kinda tricky thing is that my Explorer Bar is multi-threaded, so I can't just implement my singleton accessor using a hashtable keyed on the thread ID. If there were a way to access a thread group ID, or some sort of way to figure out which thread ID or IE window owns that particular CLR instance, that would be helpful. So any suggestions, managed or unmanaged, would be helpful. Maybe I simply need to rearchitect everything, even though now really isn't the best time for that. I'd rather be able to add a few lines into my singleton accessor (Singleton.Instance) instead. Thanks! Arun

Thanks! Turns out it was an invalid (empty) launch condition that lingered around instead of being deleted.

I've been developing a project using VS.NET 2003 for well over a year. Today I'm building the installer (Setup.msi), and when I test it out, I get the usual "Preparing to install files" (or whatever) message box, and then I get a message box that says "". I haven't changed that much in my solution lately. I had recently installed the .NET bootstrapper plug-in, but even after uninstalling that, I still get that when I build installers. Any ideas or tips? Any ways I can effectively debug the MSI or get some verbose logging? Thanks, Arun

Hi, I'm looking for a free menu/toolbar library (ideally with rebar/coolbar support ala IE6; Windows XP support would be icing). My target environment is an Explorer Bar, where top-level menus don't exist because they're not Windows applications, but I need a menu anyway. I've tried using the WinForms.ToolBar class as well as Lutz Roeder's CommandBar library. Both have flaws, perhaps a shared flaw in the WinForms.CommonDialog class clashing with the WinForms.Button class in this environment. Anyhow, it seems that the relevant articles on this site don't seem to meet my criteria, and I'd like a free library (free as in beer, although source code would be nice, too). Nothing necessarily too fancy, although icon support and font/color customization of the text would be helpful. By the way, does anyone know of a good repository of open-source .NET libraries and such besides this site? I know of WindowsForms.net and GotDotNet. They're okay. Thanks! Arun

Ugh, sorry about that nasty formatting. Let me try again: I asked my client to talk to his IT. This is the response:

If you are talking about our outgoing proxies used by internal
browsers to access the Internet, we use NetApp proxies. The
authentication methods allowed are NTLM and Basic Auth. Let me
know if this is or is not what you are looking for.

Is that consistent with your comments above? The default credential cache didn't seem to work in my tests.

I asked my client to talk to his IT. This is the response:

If you are talking about our outgoing proxies used by internal browsers to access the Internet, we use NetApp proxies. The authentication methods allowed are NTLM and Basic Auth. Let me know if this is or is not what you are looking for.

Is that consistent with your comments above? The default credential cache didn't seem to work in my tests.