I have a Click Once Deployment program that our office uses. 1.5MB of it is actual program. The rest is static DLL's like EPPlus and PDFSharp. I have a few others totaling about 7MB and I'm getting ready to use SyncFusion's Libraries which are 154MB in size.
I decided that I should leave these DLL files out of the Deployment and instead install them to the systems in question. I'm using Inno with modpath.iss to install these.
[Setup]
AppId={{6485E93B-75FC-4613-AFB7-A1800B986F7D}}
AppName="Required DLL Files"
AppVersion="1.0"
DefaultDirName="{pf}\FE Libraries"
OutputBaseFilename="Required DLL Files.exe"
Compression=lzma2/ultra64
SolidCompression=yes
ChangesEnvironment=true
[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"
[Files]
Source: "Files\*"; DestDir: "{app}"; Flags: "deleteafterinstall"
[Tasks]
Name: modifypath; Description: &Add application directory to your environmental path; Flags: unchecked
[Code]
const
ModPathName = 'modifypath';
ModPathType = 'system';
function ModPathDir(): TArrayOfString;
begin
setArrayLength(Result, 2)
Result[0] := ExpandConstant('{app}');
end;
#include "modpath.iss"
The files are installed to the correct location, and the Path is added to System Environmental.
Location
c:\Program Files (x86)\WOTC-FE Libraries
Path String
c:\Program Files (x86)\WOTC-FE Libraries
And this is an x86 compiled application.
However, the program won't run any functions requiring these DLL files. I get errors that state that the registered DLL file isn't installed.
System.IO.FileNotFoundException: Could not load file or assembly 'EPPlus, Version=4.0.5.0, Culture=neutral, PublicKeyToken=ea159fdaa78159a1' or one of its dependencies. The system cannot find the file specified.
File name: 'EPPlus, Version=4.0.5.0, Culture=neutral, PublicKeyToken=ea159fdaa78159a1'
So am I missing something?
Related
There is an error System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Management, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.'.I figured when the System.Management.dll is in the output directory, the error will be gone.
It is reference using NuGet but I couldn't get libraries in NuGet to be copied to the output folder. So I thought of adding the physical System.Management.dll file into my project and and reference it as assemblies (right-click project -> Add Reference -> browse to library) thenset 'Copy Local' to True. However, the dll still won't get copied over to the output folder.
The application is on .Net 6. Is there a reason behind why I can't copy this library like other?
A .NET6 project would normally use System.Management version 6.0.0.
The error suggests that there is another package in your project that explicitly depends on 4.0.0.
Without knowing the specifics of you projects, I suggest:
inspecting the build output for warnings about package version,
upgrading 3rd party packages in your solution.
Figured out I could copy nuget package references to output directory by setting this attribute in the project file
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Then the nuget referenced packages will be copied to the output directory.
I'm trying to register a number of DLL's as part of my installer. I'm using the regserver flag, and it works perfectly for most of the DLL's. However, one DLL fails to register. It tries to load other DLL's and fails if it can't find them in the current directory. It registers cleanly if regsvr32 is run manually from the {app} directory.
Is there any way to set the working directory for the regserver flag? Or the whole installer?
For now, I'm working round it via a [Run] entry:
[Run]
;Register components that are "special"
Filename: "{sys}\Regsvr32.exe"; Parameters: "/s Awkward.dll"; \
WorkingDir: "{app}"; StatusMsg: "Registering components ... "; \
Flags: runhidden;
But this is not ideal, as I suspect I also ought to add an [UninstallRun] section and add an unregister command. I'd hoped I could do:
[Files]
Source: "{#mysrc}\Awkward.dll"; DestDir: "{app}"; Flags: regserver; \
WorkingDir: "{app}"
Is there an easier way to register/unregister from a specific directory?
You cannot. The regsvr32.exe that Inno Setup runs internally to (un)register DLLs is explicitly run from a system directory (typically the C:\Windows\System32).
Your workaround is the best way.
Just add an equivalent [UninstallRun] entry to unregister the DLL:
[UninstallRun]
Filename: "{sys}\regsvr32.exe"; Parameters: "/u /s Awkward.dll";
WorkingDir: "{app}"; Flags: runhidden;
Or even better, fix the DLL not to rely on a working directory. You can use the LOAD_WITH_ALTERED_SEARCH_PATH flag for the LoadLibraryEx.
See also Dynamic-Link Library Search Order.
I'm getting an exception "Could not load file or assembly 'ImageMagickNET.dll' or one of its dependencies. The specified module could not be found." while implementing using ImageMagick.dll.
How can I over come this exception?
I am using Visual Studio 2010 for development on a windows 7 machine.
ImageMagick version: 1.0.3484.35397
Run time version : v2.0.50727
Add a Reference to the 'ImageMagickNet.dll' found in the 'bin\ReleaseQ8' or 'bin\RealeaseQ16' folders, choose one of them.
After that you have to download the ImageMagick 6.5.3-10 version DLLs for Q8/Q16 because the ImageMagickNet was built to this version. (I found all versions at this link: http://imagemagick.codeplex.com/releases/view/30302 For example, for Q16 download: ImageMagick-6.5.3-10-Q16-windows-dll.exe)
Then install it and copy all DLL files from 'C:\Program Files\ImageMagick-6.5.3-Q16' to your bin folder. Now you should be able to run it properly.
I have very simple managed CA which uses Microsoft.Deployment.WindowsInstaller:
[CustomAction]
public static ActionResult TestDtf(Session session)
{
MessageBox.Show("Test");
ActionResult result = ActionResult.Success;
return result;
}
I compile this with net4. I have a Managed CA in InstallShield2012 'stored in binary table' with method signature method=TestDtf, arguments=value:MsiHandle,Parameter:Microsoft.Deployment.WindowsInstaller
I'm not sure I'm calling this right, but even this isn't my immediate problem. The problem seems to be that msiexec only looks in the system folder for Microsoft.Deployment.WindowsInstaller.dll, instead of somewhere like the folder where I have just installed this assembly and confirmed it is there after CopyFiles.
Here is partial log:
InstallShield: Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Deployment.WindowsInstaller, Version=3.0.0.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.Deployment.WindowsInstaller, Version=3.0.0.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad'
at System.Signature.GetSignature(Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType)
at System.Reflection.RuntimeMethodInfo.FetchNonReturnParameters()
at System.Reflection.RuntimeMethodInfo.GetParameters()
at InstallShield.ClrHelper.CustomActionHelper.PrepareParameters(EntryPointInfo info, Boolean& anyHidden)
If I manually drop the Microsoft.Deployment.WindowsInstaller.dll into syswow64, it loads fine. Not sure I want to install this to our clients system folder however...
How do I set up my installer so that it can find Microsoft.Deployment.WindowsInstaller.dll?
You are going about this all wrong. When you build the DTF project FOO you get FOO.DLL and FOO.CA.DLL. It's the FOO.CA.DLL that you add to InstallShield as a Windows Installer DLL custom action. DTF wraps FOO.DLL inside FOO.CA.DLL and packages any other files including the Microsoft.Deployment.WindowsInstaller.dll interop in there for you.
Take a look at:
http://blog.iswix.com/2008/05/deployment-tools-foundation-dtf-managed.html
Rename the FOO.CA.DLL to FOO.CA.ZIP and open it in 7Zip or WinZip. You'll see the other files in there.
It looks like the way to solve this is to create an entry in the ISClrWrap table of:
Action: {nameOfCustomAction}
Name: Dependency0
Value: Path to the dependency in this case Microsoft.Deployment.WindowsInstaller.dll (you can use a path variable with this)
I have a project in which I have some C# classes which I am building using csc in my ant script. I have also have written some unit tests which I want to test with NUnit2.6, My test class and actual class refer to one DLL which is compiled with String Key Name (.snk), if I install thi DLL in my GAC (gacutil /i myDLL.dll) everything works fine. As soon as I uninstall this DLL from my gac I get following error for all the test during the build when I try to run my test using NUnit;
Test Error : fromJDynTest1
[exec] System.IO.FileNotFoundException : Could not load file or assembly 'myDLL, Version=5.1.0.0, Culture=neutral, PublicKeyToken=c0409b584f86b2d6' or one of its dependencies. The system cannot find the file specified.
[exec] at fromJDynTest1()
...
...
Does anyone know how to resolve this. Let me know if you need any other information.
Thanks
--
SJunejo
The code you are testing cannot see the assembly in question when you place it in the gac it can see the assembly. You need to ensure that the code you are testing has the assembly in the bin directory when compiled (perhaps copy local is set to false in your project on the assembly reference).
The reason I am sure it is not a dependency (which is mentioned in the message) is because the situation is resolved when the assembly is placed in the gac. This error is not likely caused because the assembly is strongly named.
Failing that the test code refers to the assembly and that test code either doesn't have a reference or has the same problem (not in its compiled directory).
Would help if you posted the actual test or structure of the project.
.net locates assemblies as follows:
Determines the correct assembly version by examining applicable configuration files, including the application configuration file, publisher policy file, and machine configuration file. If the configuration file is located on a remote machine, the runtime must locate and download the application configuration file first.
Checks whether the assembly name has been bound to before and, if so, uses the previously loaded assembly. If it failed before it will fail again now.
Checks the gac. If the assembly is found there, the runtime uses this assembly.
Probes for the assembly (if you open up a .csproj file in a text editor you will see hintpaths, which try and help .net find the assembly).