Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
In the documentation 64-bit Installation Limitations the following is said:
You cannot load/use 64-bit DLLs in the [Code] section, because Windows does not allow 32-bit processes to load 64-bit DLLs (and vice versa). A 32-bit process can, however, launch 64-bit EXEs. Use the Exec function or the [Run] section to do that.
Here LoadDLL it is said that LoadDLL function is deprecated and there's a link to Using DLLs and .NET assemblies instead. But there's nothing about bitness or LoadDLL function in here. Why would I need to use the LoadDLL function anyway and is there a way to use 64-bit DLLs in my [Code] section?
Inno Setup is 32-bit, so it can load 32-bit DLLs only. The bitness of the system has no effect here. The documentation you quote is correct and absolutely clear:
You cannot load/use 64-bit DLLs in the [Code] section, because Windows does not allow 32-bit processes to load 64-bit DLLs (and vice versa).
That does not mean there's no solution for your specific problem, which you are trying to solve by loading the 64-bit DLL. But you have to ask about that specific problem.
Note that Inno Setup can register 64-bit DLLs, as they are registered using an external process regsvr32, not by Inno Setup 32-bit process itself. There's 32-bit and 64-bit version of regsvr32. I believe you need to (and Inno Setup does that) to execute the right version of regsvr32 according to the bitness of your DLL.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I need to create MSI using Wix. My application has Active X control. When any user gets connected or visit the URL on the web my application needs to be installed in the user machine.
The path where I need to install is C:\Windows\Downloaded Program Files\CONFLICT.xx and this folder should contain the file ATL80.dll, app.dll, MSVCP80.dll MSVCR80.dll.
I saw few articles but got confused with them. please let me know how to start for this and what steps i need to follow in order to make MSI.
There is more to this: Packaging ActiveX Controls.
Essentially a web page will request a signed cab to be downloaded and installed via a CODEBASE URL, like this:
(sample from the Microsoft article linked above)
<OBJECT CLASSID="clsid:dcf0768D-ba7a-101a-b57a-0000c0c3ed5f"
CODEBASE="http://webserver/time.cab"
ALIGN="CENTER" WIDTH=270 HEIGHT=26 ID="T1"><PARAM NAME="Interval" VALUE=1000>
<PARAM NAME="Enabled" VALUE=1></OBJECT>
The requested cab is downloaded (time.cab), and installed (standard Microsoft cab installation / extraction). The next time the web page is opened the Active X control should work as expected. That's the normal case (admin rights are required for this to work). A successful install here can be captured and packaged as an MSI. Heavy cleanup is required though, due to all the certificates that are involved to complete the install. None of the certificates are required in the MSI as I recall, since an MSI runs with admin / elevated rights and dump files straight in the folder. Quite a security problem if you ask me, but these cabs are rarely deployed this way. Unsigned cab files won't work though (unless IE is customized).
The CONFLICT folder that is created in this users case indicates that there are discrepancies between the installed files from the cab and the version of those files specified and expected by the web page. This causes IE to trigger a new CAB download. Upon discovering the same files already exist in C:\Windows\Downloaded Program Files\ a new CONFLICT sub folder is created each time, and the user gets prompted for a new Active X installation every time the page is opened.
You must work to resolve the file versions specified by the web page and the versions of the files found in the cab. These versions must match. I can't recall all the details, but it might be that all that is checked is the CAB file version:
(Sample from this Microsoft article)
<object id="CommonDialog1" width="32" HEIGHT="32"
classid="CLSID:F9043C85-F6F2-101A-A3C9-08002B2F49FB"
codebase="http://activex.microsoft.com/controls/vb5/comdlg32.cab
#Version=1,0,0,0">
</object>
This is really a question about the Visual C++ redistributables because ActiveX controls installed from a web page don't need installing with an MSI. If that's all you're doing then the short answer is that you get hold of the VC 2005 redistributable and run it, this kind of thing:
http://www.microsoft.com/en-us/download/details.aspx?id=3387
This installs the C++ support files like ATL80.dll etc in the right places and it just works. You don't get much say in where they go:
http://msdn.microsoft.com/en-us/library/ms235316(v=vs.80).aspx
It's dangerous to have your private versions of those Dlls because there are security fixes for them, and if you have a private copy that the MS security updates can't find and fix then you effectively become responsible for maintaining them on the client systems.
On the other hand, I can't be sure from your question if you have a separate MSI file with a lot of other stuff in it (not the ActiveX) that you want to install by having people download it.
I am trying to use the SQLite's .Net DLL to access some data on a local SQLite database. The problem is that i need a way arround this error because i need to develop a software for 32/64 bits platforms (by using VB.Net not C#).
How can i stick to the 32bit version of the DLL to allow 32bit users of my program use it too?
If it's not possible to work with the 32bit version of SQLite's DLL, is it possible to include both versions in my Installer and programaticly choose which version of the DLL should be used?
Or..is there any other way to access SQLite databases without this particular DLL? (Things in C/C++ are much easier when it comes to SQLite usage as i remember)
Thanks!
If you change your Target Platform to x86 instead of AnyCPU your code will be emitted as 32bit code also on 64bit systems and you could use just the 32bit dll of SQLite.
If you think that you are loosing some value working exclusively with x86 then I can give you this reference where the PRO and CONS of AnyCpu are critically examined.
To change the Target Platform use:
Menu BUILD, then Configuration Manager
Choose x86 from the Active Solution Platform combo.
If you don't have an x86 choice,
choose New and Select x86 and copy the default settings from AnyCpu.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have built a project using VS 2010 and I have 2 reports I am creating within the project. While in VS2010, I can debug the program and the reports work perfectly.
Now I have come to the point where I want to publish my project and install it on a machine that my program will be used on. I tried 'Publishing' my project and running the 'Setup' file on the other computer and I get the following error:
Unable to install or run the application. The application requires
that assembly CrystalDecisions.ReportAppServer.CommonObjectModel
Version 13.0.2000.0 be installed in the Global Assembly Cache (GAC)
first. Please Contact your System Administrator.
Doing some research, I have found out that you can manually change the GAC or have Windows Installer fix it for you. To be honest, I don't know where the GAC is or how to modify it. My ideal solution would be to figure out how to setup Windows Installer to fix the GAC and configure Crystal reports however to get my project to run on a basic machine.
Can someone help me setup Windows Installer to install the appropriate Crystal Reports Engine so my project will work??
I am new to Windows Installer, so overkill on details won't bother me a bit!! Thanks so much in advance!!
You can try adding a Crystal Reports runtime installer as a prerequisite to your main package. You need the one with version 13.0.2000.0.
You can read more about prerequisites here:
http://msdn.microsoft.com/en-us/library/77z6b8tz(VS.80).aspx?ppud=4
http://msdn.microsoft.com/en-us/library/ms165429(VS.80).aspx
http://msdn.microsoft.com/en-us/library/ms165429.aspx
You could also try setting CopyLocal=True for the crystal references.
After having found the answer to my question about the 64-bit version of MSBuild attempting to load 32-bit extensions, it has now become necessary for me to determine whether the 64-bit or 32-bit version of MSBuild is running so I can load the correct version of the DLL.
I can check the $(MSBuildBinPath) variable against a list of known paths, but that will not work if MSBuild is running from some non-standard location. This is not an elegant solution.
Is there some way to reliably determine whether the currently running MSBuild (or other process hosting the MSBuild engine) is 32-bit or 64-bit?
Have you considered writing a custom MSBuild task that returns bitness of the current process?
See How to detect Windows 64-bit platform with .NET? for an example.
There is a related question at Find out the "Bit"ness of the current OS in MSBuild. In that question there is an answer by Blindy stating:
On a 64-bit OS, the following variables are defined:
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
So just test for ProgramFiles(x86) and if it's empty, use ProgramFiles.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I keep hearing about DLL hell - what is this all about?
It's when Application A installs a Shared DLL v1.0, Application B comes and updates the Shared DLL to v1.1 which should be compatible but there are slightly different behaviors, then App A stops working correctly and reinstalls v1.0 then App B stops working ... now imagine this with more than 2 apps let's say a dozen: DLL Hell.
DLL hell was mostly from the COM days, where a COM dll had to be registered, and clients of it would look it up in the registry. It was a nightmare because the filesystem (*.dll, *.ocx) could be modified leaving obsolete entries in the registry. Apps would stop working, it was horrible.
You'd then get the scenario where a new app installs and registers a new version of the DLL, thus breaking apps that really wanted the old version. You'd reinstall the old app, and break the new one in the process.
With .NET, there's no need to register the DLLs (the GAC is a special case, and has provision to avoid the versioning issue described above), the loader just picks up assemblies by looking in the correct paths.
In a nutshell in the good old COM days each COM component had to be registered (an entry was created in the registry) before it was used. Then your program would create a new object by supplying the type name (which was a key in the registry). And now you didn't have any control over which dll would really be loaded, would any other software register some newer/older/completely different version of this dll, etc.
Simple - in previous versions of windows, it was possible to have multiple applications all trying to access the same shared library. No problem there, that's why they are shared. the problem comes when different apps were trying to access different versions of the same assembly from a central location. Providing all the later versions of the dll are backward-compatible, and that you have the latest version there should be no problem, but if you install an app that requires v2, and then install and app that requires (and includes) version 1.x, you may find the first app stops working (because the v2 dll has been overwritten with v1.x).
Recent versions of windows are capable of storing multiple versions of a dll, and supplying the correct one on request.
It happens when an application installs a dll into the system, and another application replaces it with another version of the dll which is not compatible with the older one.
It is not a problem in c# (and .NET in general) because .NET assemblies are smart enough to be version-aware (and .NET has the GAC which manages different versions).