I am working on a Setup program which creates a .msi file. There is a CustomAction program associated with it which is written in C#. There are three COM object references made in this CustomAction program which are necessary in order for it to work. They are as follows.
Active DS IIS Namespace Provide (C:\Windows\System32\inetsrv\adsiis.dll)
Windows Script Host Object Model (C:\Windows\System32\wshom.ocx)
NetFwTypeLib (C:\Windows\System32\FirewallAPI.dll)
As added information, following are the tasks I use these DLLs in my program for.
To set MIME settings for a particular file type.
To create a desktop shortcut to a folder.
To register a program as a firewall exception
.
Now, here is my problem. When I rebuild the C# program and execute the CustomAction program from within Visual Studio, it works fine and I can get the above three tasks done like a charm. However, when I actually build the .msi and try to execute it and install the program on my system, it gives an error. I'm using a Japanese OS so it gives the error in Japanese so I'll try to translate the error message in to English as best as I can. The error is something like this:
*
File or assembly 'Interop.IISOle,
Version = 1.0.0.0, Culture = neutral,
PublicKeyToken = null', or one of its
dependencies could not be loaded.
Cannot find the file specified.
*
This particular error message is given because it relates to the first dll (adsiis.dll) because it is the one which contains the IISOle namespace. Similarly it gives error messages relates to all the three COM objects which I made references to from my program. Now what I can understand from this is, somehow when this code is inside the .msi file it cannot find the appropriate COM objects. I'm really confused why this happens as the Setup gives the same error when I try to install the program even on the same machine which I used to code the CustomAction. Funnily it executes flawlessly from withing Visual Studio Interface. Please do help me with this. Thanks in advance!
Note that I'm working on Windows Vista Business, but I need my Setup to be able to install on a variety of Windows OS ranging from Windows Server 2003 to Windows 7.
Just encountered this today. Go to "Turn Windows features on or off" and scope out everything under IIS, including the IIS 6 stuff.
Make sure that the feature "IIS Metabase and IIS 6 configuration compatibility" is checked, found under "Internet Information Services" > "Web Management Tools" > "IIS 6 Management Compatibility".
Anton, finally I found out what was wrong.
When I reference, for instance, dsiis.dll then Visual Studio places an Interop module, namely Interop.IISOle.dll inside the bin directory of my CustomAction program. Which is where the CustomAction.exe can also be found. It does the same process when I reference the other two COM objects; wshom.ocx and FirewallAPI.dll. But my actual setup program which is written using Wix copies this CustomAction.exe to some other directory and the .msi uses that particular CustomAction.exe file. The problem occurs since Interop.IISOle.dll (and the others as well) cannot be found there. (The error message said what I needed to look for from the beginning it seems; I was foolish not to look for it but thinking there might be bigger problems)
So this is what I did. I instructed the Wix project to copy those Interop DLL files to the same place where the CustomAction.exe which is used by the installer resides. That solved the problem so easily.
I'm totally a newbie when it comes to Wix, plus we needs to use the CustomAction for 2 and 3 because of some reasons.
Related
I have a predominantly managed c# .net 4.6 app that is trying to call into a c++ dll (that is also built as part of the solution), Visual Studio 2017.
I get this exception:
"System.IO.FileNotFoundException: 'Could not load file or assembly 'XXX.dll' or one of its dependencies. The specified module could not be found.'"
There doesn't appear to be any more information. The dll is in our binaries directory with all our other dlls that load fine, and the exe that is being run in the debugging session (The start up project).
I've checked the solution configuration manager, its building the dll as x64 in our Debug|Any CPU config, which makes sense.
No one else in the office has this issue, and I didn't have this issue on my old computer (I'm getting now trying to set up my new dev computer, which is the exact same specs as the old one) Windows 10.
I have the WindowsSDK 8.1 and 10 installed, and the vs c++ redistributes.
Any Ideas? Or atleast, and idea how I can get more info about whats actually going wrong? (This exception is frustratingly vague).
You’d want to use Fuslogvw.exe, the assembly binding log viewer. It can be started by launching the Developer Command Prompt for VS. The first thing is to enable logging, and the simplest way is to run as administrator (as a comment to an answer here correctly points out); you can alternatively set the ForceLog regkey specified here if running as a regular user account.
There's also a small video I did a while back to test how this works. You can find this in this article. Just scroll to the bottom, it's within the 2nd question starting from the end.
If that doesn't work, run Process Monitor and set a filter for your specific .dll and see what the CLR does in detail when searching for it.
I accidentally deleted my project from visual studio2013/projects/myproject. I did a system restore and got the folder myproject. I am unable to see my code form or design form but I can run my application.
What d I have to do to be able to edit my code?
System Restore will only revert the computer's state (including system files, installed applications, Windows Registry, and system settings), not user files, and your sourcecode files are user files.
Since you can still run the application, then you must have a compiled executable somewhere. I suggest that you download dotPeek from JetBrains and then you can open your application up in it and decompile your assembly back into source code.
The code will be a bit ugly; your nice, meaningful variable names will probably be gone, but at least it's a starting point. Here's the link to dotPeek. https://www.jetbrains.com/decompiler/
BTW, I'm assuming that you've already tried to get the files back from the Recycle Bin.
I have a problem regarding the Visual Studio Setup Project and uninstalling an application.
This is a very basic installer, installing an ApplicationLauncher.exe C# .NET 4.0 console application and an Application.Common.dll (a dependency of the application ApplicationLauncher.exe).
The installation is a success, copying both the exe and DLL into the program files folder C:\Program Files (x86)\Company\ApplicationLauncher\.
My problem comes when uninstalling the application (through the MSI) - the uninstall seems successful, however it leaves Application.Common.dll behind, and doesn't remove it as I would expect.
I've used ProcessExplorer to make sure nothing else is using the DLL, no explorer windows are open during the uninstall.
Is this the expected functionality and do I have to create a custom action to remove this DLL? Or have I done something wrong? :S
It seems I was able to fix this issue by renaming the solution and product name of the application, I'm not sure how this fixed it, but it did.
My only thoughts here is this traversed through to the installer, where the application installed into a different folder, thus not applying the same permissions to the DLL..
It's not expected, no. It will happen if you ever done any of the following with your setup and installed it:
Marked the file Permanent.
Marked the file SharedLegacyFile true.
These are project settings, but if you set either of them and do the install it will stay behind. You can unset them in the setup project but that's too late - you've marked that component permanent or sharedlegacy on the system. If you use a brand new system, like a fresh virtual machine, reset these values if they are set and rebuild the MSI and do the install/uninstall does it still happen?
I had the same problem. Then I have tried to install and unistall my app on Windows XP and that had worked.
Renaming the ProductCode is treating the symptoms not the cause. The problem occurs when the uninstaller doesn't remove the dll. The next install will use the dll again and can't remove it on an uninstall event because it's still used by the other program.
These steps hopefully solve the problem:
Install your Software
Open CMD (with admin privileges) and run:
msiexec /x {ProductCode} /L*V "C:\CustomPath\FileName.log"
The ProductCode can be found when hitting F4 on the Setup Project
Open the log file and search for the lines that look something like this:
Disallowing uninstallation of component: {6CEC09F6-9108-7062-A692-2BCBACEE3BD8} since another client exists
Disallowing uninstallation of component: {A0A0FA84-CC0D-C5C4-1F57-169788C4482D} since another client exists
Disallowing uninstallation of component: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} since another client exists
All these components have to be removed from the registry by hand. To do this the GUID (e.g. {6CEC09F6-9108-7062-A692-2BCBACEE3BD8}) first has to be converted into a packed/compressed GUID (e.g. 6F90CEC6801926076A29B2BCCAEEB38D). I found a Website where one can run a script to do this. Find the following code on the website and replace the right side with the GUID from the log.
string inStrGUID = "{6CEC09F6-9108-7062-A692-2BCBACEE3BD8}";
Open the registry (as an administrater) and search (Edit -> Find...) for the compressed GUID (uasually it's somewhere in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\)
Delete the folder that is equal to the compressed GUID. The values inside the folder should be a path to the dll.
Once deleted select the parent folder (...\S-1-5-18\components) and hit Edit -> Find...
Repeat these steps (4-7) for all components from the log file.
It's also a good idea to delete all files still present in the original folder that weren't uninstalled.
Can one prevent this from happening?
I don't know. This really isn't that easy to reproduce. Some other post on SO have suspected the install/uninstall option in Visual Studio to be the cause of the problem but I have a different theory:
This bug might be the result of RemoveExistingProducts in InstallExecuteSequence in the Setup being executed too late and therefore not removing dlls at the right time. This bug is known for years and can be fixed by doing this. If you need help with Orca this explains how to install it.
I have looked this problem and i found many entries on the net about it.. but none that i could understand. maybe you can help?
I have a dll file (created from a c script) and i created a GUI using visual C# 2010 for my program.
I have tested my application on 5 different computers.
On my computer and the computer where i created the application, the user interface and the program runs without any trouble.
However when i pass it to other computers i receive the following error line AFTER execution of the program (which means that the user interface opens, but when i insert all my values and run the code stored in the dll file i receive the errir)
"Could not load file or assembly "ParsingDll.dll" or one of its dependencies. the specified module could not be found."
All the computers run microsoft windows 7 and are 64bit.
The dll file "ParsingDll.dll" is the one containing my code executed by the GUI, and it is in the same folder as the executable.
Ill appreciate it if someone could help me out with this and take it step by step with me as im new to these kind of stuff.
Many thanks to you all.
One of the used assemblies might require a (native) library that isn't available.
You can enable fusion logging to find out exactly what is causing the trouble:
This logs what gets loaded, and where the fusion loader looks for assemblies, turn on fusion logging in the registry:
Add the following values to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Add:
DWORD ForceLog set value to 1
DWORD LogFailures set value to 1
DWORD LogResourceBinds set value to 1
String LogPath set value to folder for logs e.g. C:\FusionLog\
This folder must exist, and end with the backslash
(instructions copied from How to enable assembly bind failure logging (Fusion) in .NET)
Import the dll, and compile all the projects including the dll. Refresh, restart, reboot the computer if necessary. Make sure the DLL exists on the computer. Reboot, refresh, recompile, clean should fix it.
Check to see if your ParsingDll.dll is blocked. You can check by looking at the dll file's properties. If it is blocked, there will be an "Unblock" button.
I have been using HTMLAgilityPack from within Visual Studio without a single problem. I extracted HtmlAgilityPack to my HD, and added the file HtmlAgilityPack.dll as a reference to my C# application. Again everything is working splendid from within Visual Studio. I then built my solution and attempted to run my application outside of visual studio (as a standalone desktop executable file) and I get the following error when I run my application:
"Unhanded exception has occurred in your application. If you click
Continue, the application will .... Could not load file or assembly
'HtmlAgilityPack, Version=1.4.0.0.
Culture=neutral.PublicKeyToken=bd319b...' or one of its dependencies.
The system cannot find the file specified."
How is is possible that the system can't find the file specified? Visual Studio had no trouble finding it...
I can provide any additional information upon request.
Thank you for any help with this one - Evan
I figured this one out. The problem was that I was using an EXPERIMENTAL copy of HtmlAgilityPack. I changed over to the 'full' version HERE and everything works great now!
The assembly HtmlAgilityPack.dll is needed for your program to run. At runtime, the CLR will look for it in several palaces. The most convenient ones are:
GAC
Local directory (that's where VS finds it when it executes it).
So either make sure HtmlAgilityPack.dll is in the same directory as you EXE, or put it into the GAC (using gacutil.exe).
Build the solution not only the project.
Select your solution and press ctrl + Shift + B