I'm attempting to register a GIS based dll on a test computer and I'm having problems loading in the tlb file with ArcGIS 9.3.1 - ArcMap on the test computer. When I attempt to load the tlb file is says "No New Objects Added". I created the dll file using Visual Studio 2010. The tlb file loads fine on my developer computer. I'm registering the dll/tlb on the test computer by using cmd.exe command (see below).
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe C:\Temp\My.dll /tlb:My.tlb/codebase
The registration replies as successful and the item is listed in the Component Category under the MX Commands category. Below is the COM GUIDs portion code that I'm using within my class.
#Region "COM GUIDs"
Public Const ClassId As String = "1bf94bdf-907c-4026-816f-50feb7a2a976"
Public Const InterfaceId As String = "7ba8a4d5-d15c-4d95-a819-a3e7cbe84533"
Public Const EventsId As String = "2ab51582-47e1-490c-899d-a80992c20fdf"
#End Region
The OS of the developer computer is:
Microsoft Windows XP 32bit,
Version 5.1 - Service Pack 3
AND
The OS of the test computer is:
Microsoft Windows XP 64bit,
Version 5.2 - Service Pack 2
Do I need to do a Windows Update on the developer computer (to 5.2) or is there something wrong in my dll/tlb registration method?
Thanks for your help!
UPDATE:
The ArcGIS software on the test computer is installed under the C:\Program Files (x86) location.
I think you need to register it using the 64-bit version of RegASM on your target PC. You should find it in:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727
^^
Note that I'm assuming that you have compiled your code to MSIL (by selecting AnyCPU as the platform). If you have compiled it to target 32-bit, then you will need to change that.
This is because a 64-bit process cannot find registrations performed by the 32-bit version of RegAsm, and vice-versa.
Related
I have been trying to make SQL Server CE work with Visual Studio 2005 for the past 4, 5 hours. but no luck. When I run my application I get the following error:
Can't find PInvoke DLL 'sqlceme35.dll'
I have read countless threads and articles on it but unable to make it work. Using the following tools:
Windows CE 5.0 device running Intel Bulverde processor
Windows XP 32 bit with Visual Studio 2005
SQL Server Compact 3.5
Here is what I did.
Created a new "Smart Device" project and selected "Windows CE 5.0"
Installed SQL Server Compact 3.5 (on Windows XP) which installed a bunch of folders and files
In my project I added a reference to "System.Data.SqlServerCe.dll" which is inside folder where SQL Server Compact 3.5 is installed
Then I wrote a few lines code as below which I copied from http://msdn.microsoft.com/en-us/library/aa226134(v=sql.80).aspx
SqlCeEngine engine = new SqlCeEngine("Data Source = Test.sdf");
engine.CreateDatabase();
conn = new SqlCeConnection("Data Source = Test.sdf");
conn.Open();
Then I installed "sqlce.dev.ENU.wce5.x86.CAB", "sqlce.repl.wce5.x86.CAB" and "sqlce.wce5.x86.CAB" from "wce500\x86" on target device which created a bunch of DLL files in folder "Microsoft SQL Server Compact Edition"
Then I ran my program but I got error as described above. The error is being thrown by line SqlCeEngine engine = new SqlCeEngine("Data Source = Test.sdf");
I thought may be I need to copy all DLLs from folder "Microsoft SQL Server Compact Edition" to my application folder on target device from where my program was running so I copied all files but still same error.
And then I thought may be I need to use "armv4i" instead of "x86" so I first installed "sqlce.wce5.armv4i.CAB", "sqlce.repl.wce5.armv4i.CAB", "sqlce.dev.ENU.wce5.armv4i.CAB" and as expected it didn't work. So I again copied all DLLs into my program folder but no luck.
What am I doing wrong?
The Bulverde, IIRC, is the PXA27x series processor which is definitely an ARM core, not an x86, so you must use the ARM binaries.
Start by making sure you have a factory-reset device (the registry would be the important bit to reset).
Then use the CAB (or just the binaries directly) from this folder:
%PROGRAM_FILES%\Microsoft SQL Server Compact Edition\v3.5\Devices\wce500\armv4i
Make sure that the System.Data.SqlServerCe.dll assembly is on the device (typically in your application folder).
If it still fails, you probably are missing a dependency. Run depends.exe (on the desktop) against the SQL Compact binaries to see what they need and ensure those are on your target.
I have a windows form application which is being installed on client pc by using msi file trough active directories, application is a 32bit app which is being deployed to a 32 bit and 64 bit windows systems and as we know application folder names are different between 32 and 64 bit systems, Program Files and Program Files(x86), also during installation application shortcut is placed in startup folder so app will be started when PC us powered up.
Question: Is there a chance to build msi by Windows Installer provided by Visual Studion in such a way that it will check what operating system its being installed at and place the shortcut in to start up folder with correct URI, to Program Files\Applicaiton\ or Program Files(x86)\Applicaiton?
Thank you!
Windows Installer packages are platform aware (x86, x64 ). Windows Installer doesn't support 64bit packages running on 32bit platforms or 32bit packages writing to 64bit ProgramFiles.
You can compile your EXE as AnyCPU and even though it's installed as 32bit it'll execute as 64bit. Although the Visual Studio team has moved away from that and compile as x86 by default in recent versions of Visual Studio.
Upon initialization, the Windows Installer gathers information about the operating system and automatically sets properties that can be used in optional conditional statements used by the setup application, such as VersionNT64 and "System Folder Properties"
In cases where it is necessary for the setup to know this information, it is preferred practice to allow the Windows Installer service to determine folder locations rather than try to hard-code this information into the package.
I have an application that allows me to scan images on my development PC which works successfully. It uses the Microsoft Windows Image Acquisition COM ActiveX dll. I am running VS2008 on Windows 7 64 bit.
I am having problems trying to deploy the Interop dll using ClickOnce. This component is referenced through the VS project in the normal way (and copy local = true). When I install the application on a Windows XP machine, I get an error saying that the library is missing (i.e. it wasn't installed / registered correctly). Having looked in the System32 directory, the dll is not there, so it has to be deployed via my app.
After looking on the web and trying various solutions, I then tried Microsoft's 'Registration-Free COM' method here: http://msdn.microsoft.com/en-us/library/ms165432%28VS.80%29.aspx
However, changing the Isolated property to True then caused 2 compilation errors due to duplicate entries in the registry. Having sorted out these entries out manually, I then deployed my app again with the supposedly isolated COM component, but when I try to scan a document I now get this message:
'The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll'
I feel like I'm going round in circles with this one. Can someone please enlighten me on how to deploy the WIA interop via ClickOnce for all versions of Windows from XP onwards?
Your help will be greatly appreciated.
Thanks
Don't copy system DLLs from your Win7 machine to the XP machine, that can't work. It would have been easier if you named the file, I would guess at wiaaut.dll, the WIA Automation provider. It probably just isn't installed on the XP machine.
Ask the client to install this download on the machine. You don't need reg-free COM, these are system components.
I have installation solution that have installer project (not web installer but simple installer) that installs NT services, web service and web sites with help of additional two projects of dlls with my own code that performs my installation step. In user actions of installer project I call installer function of one of those projects, and this project calls to installer of second project: installer -> MiddleCaller -> InstallationCore.
All this developing on Windows 7 and work fine when I compile all in 32 bit.
The project must run on Windows 2008. Because of some reasons all must be in x64 bit.
For this purpose, in MiddleCaller and InstallationCore I click right button of mouse on project -> build -> targer x64. For to move installer project to 64 bit in properties of installer (when project is active) I check: Target platform: x64.
When I run installation on x86 I get error:
The installation package is not supported by this processor type"
And this is good, because now I know that my installation compiled in 64 bit, but when I run this on windows 2008 I get:
Error 1001. Exception occured while initializing the instance:
System.BadImageFormatException: could not load file or Assembly
'MiddleCaller, v...' or one of its dependencies. An attempt was
made to load a program with an incorrect format.
Any one has some idea what I need to do for run fine the installation on x64?
May be I still not moved the installer project to x64 bit, if yes, where I do this?
Thank you for ahead.
Found a quick tip on Microsoft's website that could be useful on troubleshooting setup and deployment projects:
64-bit managed custom actions throw a System.BadImageFormatException exception
If you add a 64-bit managed custom action to a Setup project, the Visual Studio build process embeds a 32-bit version of InstallUtilLib.dll into the MSI as InstallUtil. In turn, the 32-bit .NET Framework is loaded to run the 64-bit managed custom action and causes a BadImageFormatException exception.
For the workaround, replace the 32-bit InstallUtilLib.dll with the 64-bit version.
Open the resulting .msi in Orca from the Windows Installer SDK.
Select the Binary table.
Double click the cell [Binary Data] for the record InstallUtil.
Make sure "Read binary from filename" is selected and click the Browse button.
Browse to %WINDIR%\Microsoft.NET\Framework64\v2.0.50727.
Note
The Framework64 directory is only installed on 64-bit platforms and corresponds to the 64-bit processor type.
Select InstallUtilLib.dll.
Click the Open button.
Click the OK button.
There are some unclear things in this scenario. I understand that you are having difficulty running a 32-bit installer that calls on 64-bit assemblies. If this is correct, then what you are doing is not allowed. You cannot have 32-bit and 64-bit assemblies in the same process - that is illegal. If the 64-bit assemblies are being referenced by the installer directly, then the installer must also be 64-bit.
As clarification: I believe a 32-bit installer can install a 64-bit application, but it may only do so by copying the 64-bit files and not by actually making calls into the 64-bit files. The only way this is supported is if the 64-bit files are loaded into a different process and you use IPC to call into them, but even this is likely to be a bad solution.
In your case, I would encourage you to convert your installer into a 64-bit installer.
So, eventually, I compiled MiddleCaller and InstallationCore in AnyCpu mode, when all dll and executables that I need to install were compiled in x64 bit. All this I compiled on Windows 2008 x64 bit with x64 bit outer dependencies (like Oracle client).
I'm using msscript.ocx in my application which is an activex scripting host for windows.
Although I want to be able to use the same for XP embedded(XPe) which's highly customizable.
1.I want to know whether on XPe, msscript.ocx can be optionally installed or not?
2.Where does it get installed from, IE?
3.Or is it a windows core component which gets installed during the XPe setup?(I know one can unregister it, but can it be an optional installation)
Answering any or all of these questions will be of great help to me.
Thanks in advance.
Sam.
Microsoft's documentation of the MSScript.ocx library is somewhat contradictory on this issue. The short answer is, starting with Windows 2000, the MSScript.ocx library became part of the Windows OS. Subsequent service packs for Windows 2000, XP, and 2003 included bug fixes (1,2,3) for this library. Since that time, the library has remained part of the 32bit portion of Windows and is still included with Windows 7/2008 R2. Even 64bit versions of Windows still include msscript.ocx with WOW64 in C:\Windows\SysWOW64.
For a little history of this library's distribution keep reading.
Msscript.ocx was originally included on the Visual Studio 6 CD as a "optional" library - optional meaning it had to be manually installed. While the library was part of Visual Studio, it was migrated to being part of the Windows OS starting with Windows 2000.
This is where the confusion comes into play. Since msscript.ocx is considered to be a component of both VS6 and Windows 2000, updates were distributed in service packs for both. Even after the last service pack for VS6 was released, additional bug fixes needed to be distributed for older OS's, so a separate download was created specifically targeting Windows 95, 98 and NT4.
This download is targeted for older OS's for the simple fact that it had become a part of the OS in "modern" versions of Windows. If you are using Windows 2000 or greater, the download is unnecessary and - in my experience - can cause compatibility problems.
I think it is not shipped with Windows XP(not a 100% sure)...
But the best choice is to ship it with your installer(even if it was shipped, it can be removed). About the installing - you can put it where you want (in the program folder in Program Files is ok), the important thing is to register it.
The best choice for making installers - Wix
EDIT: reference
The Script control ships with Visual
Basic 6.0; however, Visual Basic 6.0
setup does not install the Script
Control for you. The control is
located in the CD directory
Common\Tools\VB\Script. To install the
script control, try the following
steps:
I think this answers your question....
For those having issues getting MSSCRIPT.OCX to work do the following:
Go to References in Project settings:
Microsoft Script Control 1.0
Microsoft Scripting Runtime
Microsoft Scriptlet Library
Check all those on.
you'llneed to change your development environment to produce a 32 bit version of your appliation, which for most apps won't matter.
For this goto Project,
then select Properties,
select Compile,
Target CPU: x86
In your code, and i'm using visual studio 2019,
' by using the references above the ScriptControl
' should become available for inclusion into your source c
Dim ms As ScriptControl = New ScriptControl
ms.Language = "JavaScript"
ms.Reset()
Try
ms.ExecuteStatement(RichTextBox1.Text)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try