I have a problem trying to register DLL. My OS is Windows 7 (x64).
I do it in two different ways:
1) Using regsvr32. I get message "DllRegisterServer ... succeedeed", nevertheless I can't find my CLSID in registry. (And I get "Class not registered" error trying to create an instace of component with this CLSID).In this case, I know that DllRegisterServer is never called (because I create a text file in the beginning of this function and it is not created).
2) Explicitly load my DLL and call DllRegisterServer. In this case, DllRegisterServer returns S_OK, but still I can't find my CLSID in registry and get "Class not registered" error.
I'm sure the code is correct (for it doesn't work only on my OS), so it seems that the problem is in OS. Did anyone face such a problem?
http://msdn.microsoft.com/en-us/library/aa384232(v=vs.85).aspx should explain it
Depending on whether your dll is 32bit or 64bit the registry keys are created at separate locations
Just solved an identical problem. I've manually added to the existing 32-bit COM new interface, implementation (MyNewClass) and rgs file. But when I've successfully registered my COM using SysWow64\regsvr32.exe I've noticed that my ProgId/CLSID didn't appear under HKCR\CLSID or HKCR\Wow6432Node\CLSID
So, actually I missed few thing:
I had to add OBJECT_ENTRY under BEGIN_OBJECT_MAP in MyApp.cpp file
and add DECLARE_REGISTRY_RESOURCEID(IDR_xxx) to MyNewClass.h file
resource.h
define IDR_xxx 105
ExistingCom.rc
IDR_xxx REGISTRY DISCARDABLE "MyNewClass.rgs"
Run command line tool as administrator and then run the register command regsvr32
Related
In a simple windows form application on VS 2010 I have put a ovalShape using power packs.
The simple Form
Now automatically this action puts the reference of Microsoft.VisualBasic.PowerPacks.Vs in to project properties.
when deploying this in different PC obviously the (a)powerpacks needed to be installed if this application doesn't work, (b) or it can set to "copy local = true" in reference properties so that it should sit to next with the application.
assuming (b) is not an option, since it is a solitary executable, (a) is the only option. in this way if the target machine does not have powerpacks the requirement is to notify it to the user in the first place.
apparently the dll will be deployed in when using the "VisualBasicPowerPacksSetup"
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualBasic.PowerPacks.Vs\10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.PowerPacks.Vs.dll
so the blind approach is just to check if the above file not exist then prompt user to install "VisualBasicPowerPacksSetup". but i feel its more accurate if the application able to actually check in registry level.
in registry "Microsoft.VisualBasic.PowerPacks" records in several location, thus makes a confusion.
how to identify the correct key and what should be correct way of checking this reference in vb ?
You could just try to create an object defined in the dependency and catch the resulting exception.
Handling this you could ask the user to install the package. This is probably not considered good practice but should get the job done.
We have a main application (Winforms) with several dll's referenced containing Logic and UI Layers. After some research on how to perform auto-update in a winforms application, I found a solution using AppDomain and the ShadowCopies feature.
Another executable look for updates and makes the exchange of files.
Okay, but now, I got the following situation:
I start the main application (loaded through the new AppDomain).
I open a form that is in a referenced dll ("ReferenceA"). This dll is copied and instantiated from the copy. (Great!)
At this time the system receives an update with new versions of "ReferenceA" and "ReferenceB", and makes the exchange of files.
I open another form that is in "ReferenceB". This dll is copied and instantiated from the copy, but this dll also references "ReferenceA" that is not updated by ShadowCopy because it is already in the directory.
Now the system is running a newer version of "ReferenceB" with an older version of "ReferenceA". In my test I created a new method in "ReferenceA" then I obviously got the message: "Method not found".
Any suggestions on how I can solve this?
I have designed a windows form application with a .NET 4.5 target. I am trying to install the program on a couple of co worker's systems and keep receiving the same error on both systems.
System.InvalidOperationException: DataReader.GetFieldType(60) returned null.
This program basically retrieves data from a database and stores them in an excel file. It performs some calculations on the data, but nothing with the geometry type column except for retrieving it.
-I have tried installing ENU\x64\SQLSysClrTypes.msi and ENU\x86\SQLSysClrTypes.msi on the target systems.
-I have tried referencing Microsoft.SqlServer.Types and including the DLL in the files
-I have tried referencing SqlServerSpatial.DLL and SqlServerSpatial100.DLL but it does not let me add the references.
I am now having trouble finding other resources to try. Does anyone have any ideas? Thanks ahead.
I was able to finally get this working by adding a reference to
C:\Program Files (x86)\Microsoft SQL Server\110\Shared\Microsoft.SqlServer.Types.dll
and setting Copy Local to true. Odd that the nuget package worked for me in a different project, but not this one. Anyway, hope this helps somebody!
I'm installing an Active X control that contains some COM servers. I'm using InstallShield's COM Extract at Build option to generate the registry information. This results in a lot of entries in the Registry and Class tables. (The extracted information is pretty much the same using Wix).
It appears that my COM Sever is correctly being installed except for an additional value called "InprocServer32" in the InprocServer32 key that looks like this:
HKCR\CLSID\{MY-COM-GUID}\InprocServer32
(Default) = C:\Path-to-my\file.ocx
InprocServer32 = 8tYCAGak)9S9&~swl.$?MyFeatureName>*&N$B'fk?As1x2J653?'
The only think I can make out from the extra value is the MyFeatureName which is the internal name of the MSI feature that contains the .ocx file. The key is not listed in the Registry table so it must be generated by the Class table.
The problem I'm having only happens in Windows Server 2008. It seems that the app trying to use the COM server is failing to find the path to the .ocx file from the (Default) value and instead it is finding the InprocServer32 value. This results in the app launching the MSI and then having the MSI being stuck in what seems like an infinte loop.
I'm wondering if this is a known issue in Windows Server 2008 or whether there is a way to prevent that extra value from being generated by msiexec.
I'd read this article and see if it helps you get where you want to be:
RobMen's Recommendation: Do not advertise COM information in MSI
You might want to turn off InstallShield's COM Extract at Build and instead do a One-Time COM Extract on the component in question. Then you can go into the Component Advanced section and manually manipulate the registry / com table information to be how you want it to be.
If you use WiX at all, another workflow / trick is to use Heat to build an MSI or MSM around your COM server. Then use InstallShield to edit the MSI/MSM in direct mode and the Registry view to export the Registry Keys/Values to a .REG file. Then import that .REG file into your Component in your real install project.
I can't help you diagnose what's going on, I'll just mumble a bit about what this all means. This is a counter-measure against DLL Hell. It is supposed to protect your application against some kind of other install program that could overwrite your COM server registry keys. Specifically the (Default) key which gives the location to your server DLL.
From the fake InprocServer32 value, the app can auto-detect that the Default key was overwritten and automatically launch MSI again to repair the damage. Which is what you see happening.
I thoroughly dislike the feature, it is just one more fail point in something that is already hard to troubleshoot when it blows up. And it is a useless feature, it assumes that the other installer doesn't use the exact same counter-measure. Which would have worked 10 years ago.
No idea what you'd do to troubleshoot this particular failure. Other then just punt this cr*p and let the servers just SelfReg themselves. At least you'll have something to work with when that doesn't work.
I have run into an odd problem while attempting to register a vendor-supplied ActiveX control on two different computers. On one computer, I can register the part using regsvr32, and then use it in an Access 2007 form with no problems. On the other computer, after I register the same DLL, it is simply not recognized as a valid ActiveX part by Access 2007, or any other Office 2007 program.
The ActiveX part is contained in a single DLL. I am not missing an additional file on one of the computers.
I cross-checked the exact version of the DLL on both computers using md5sum. Both DLL files are exactly identical.
I cross-checked all of the registry entries generated when the part is registered, using the Nirsoft ActiveX Helper utility. The entries are identical.
I checked Access to make sure that the part had a reference entry which pointed to the DLL.
I checked that the location of the DLL was specified as a Trusted Location in Access.
Unfortunately, I am not enough of a COM expert to know whether or not I am overlooking something odvious. Any additional ideas would be appreciated.
OK, total shot in the dark, but we have some computers in our organization the the IT has locked down pretty tight. When we run setup's they run OK and register our ActiveX components, but the first time we run the program it has to be as an administrator. After that the normal user is able to run the program.
You could try a simple VBS script to verify that the control can be created.
Using Notepad (or similar) save the following as test.vbs, and then double click it to run it.
set oTest = CreateObject("<YOUR PROGID HERE>")
MsgBox ("All Done Successfully")
You should get an reasonably descriptive error or "All Done Successfully".
This would at least point to whether its a system wide or Office specific problem.
And if you get an error it may well point to the actual problem.
OTH, if you don't get an error then you probably have an Office installation issue - which could be resolved by a re-install.