I have an Excel 2016 solution that contains C# COM components as part of the deployment. I am able to get the COM components to register OK. However, there were a couple controls that were used, that existed on the development system that need to package as well.
TreeView and ListView controls are added in the references in the VBA IDE. It referenced MSCOMCTL.OCX. I have added this file as a dependency in the installer. However, the installation fails to register the file. I suspect that there may be additional dependencies I am missing?
Related
I made a SolidWorks Addin using VB 2015. It works fine on SolidWorks 2015 but does not work on any higher release for SolidWorks (e.g. 2016, 2017). Not sure what I am doing wrong as these addins should not be release specific.
Any Help Would be greatly appreciated.
Thanks,
Pranav
This happens for a couple of reason, always associated with where the COM Interop files were and are now on your system.
The first is if you referenced the exposed COM that is available when you install SolidWorks from the screen below. This always created problems when the old version of SolidWorks is uninstalled or upgraded. Your projects will show a warning within the references in your project.
The second often happens when you reference the Interop dll from the installation location (usually C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS\api\redist\SolidWorks.Interop.sldworks.dll). This is what the SolidWorks Addin Template does by default. Sometimes if you forget to remove the SolidWorks installation directory when installing a new version of SolidWorks, it creates a folder with a different name (SOLIDWORKS Corp\SOLIDWORKS (2) by default). The problem is now the referenced dll file's path has changed and your project can no longer find it.
The best way to solve these issues is to create a copy of the dlls you want to reference in your project's folder structure and browse to them within your project like below.
Doing this will ensure that your project always references this dll, that shouldn't be removed or have its path changed regardless of what you do with your SolidWorks Installation.
If for some reason the addin template does reference this location, go to your references in the Project Explorer, and remove them, and re-point them to a local copy (not the installed files).
I added references to telerik dlls in the code, with copy local set to true. But, when I am building the project I am receiving an error randomly.
Error1Unknown build error, 'Cannot resolve dependency to assembly 'Telerik.OpenAccess, Version=2015.1.220.1, Culture=neutral, PublicKeyToken=7ce17eeaf1d59342' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.' C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets2689SMS
I am not using openaccess assembly at all. I have no idea why this keeps coming randomly. I am not even able to find the dll anywhere to add it to the project.
I was trying to use the telerik controls by dropping them to designer from the toolbox (just like typical asp.net controls). Somehow in that case, it was referencing the path of the installation folder (C:\ProgramFiles...). That's why it was failing on different PCs wherever the installation path changed (like telerik 2.0.2 instead of telerik 2.1.2).
So, I copied all the dlls from installation path, uninstalled telerik completely. Then I copied the required dll to bin folder and referenced it in solution from there.
I'm forced to use a third-party COM component in an application, and I'm having issues adding the reference to my project.
I've added this DLL as a reference to a project before, but in the past it would link directly to the DLL, such that the "Path" in the reference's properties would be filesystem path where the DLL was installed (i.e. not relative to my solution's directory). However, now, when I add the reference, the "Path" is to my project's obj directory, "Embed Interop Types" is set to True, and it's listed as an ActiveX component (which is not correct).
Then, I stumbled upon this MSDN article, which says:
If you want to add a reference to a registered COM DLL that contains an internal manifest, unregister the DLL first. Otherwise, Visual Studio adds the assembly reference as an ActiveX Control instead of as a native DLL.
Well, there you have it. That's my exact problem. I need the native DLL, but I'm getting an ActiveX Control instead. So, I did as it suggested and unregistered the DLL. However, when I then try to add the reference, I get an error saying:
A reference to ... could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
If I register the DLL again, I'm able to add it as a reference, but again, it's added as an ActiveX control. At this point, I don't know what else to do. Microsoft is very clear that I must unregister it before adding it as a reference, but then Visual Studio 2013 apparently won't let me add an unregistered DLL. Any one have any idea how to work around this?
UPDATE
So, apparently a recent update to this app made COM the only option (no directly using the DLL). The fact that it was added as ActiveX didn't mean anything. The problem turned out to be that this was a 32-bit library trying to run in 64-bits. I knew that was a potential problem, but switching the platform target to x86, still resulted in an error so I ended up chasing a red herring. Turns out IIS Express 8 runs natively as 64-bits even if the platform target of the site you're debugging is 32-bit. I had to go into Visual Studio options and uncheck the flag that tells IIS Express to run 64-bit (under "Web Projects") and then everything ran fine.
So, since adding the registered DLL was pretty much a no-go, I focused instead on trying to figure out why Visual Studio wouldn't let me add it when it was unregistered. I mean, sure, I might get an error about it being an unregistered DLL once I tried to run the project, but it should at least let me add it as a reference, regardless.
I eventually stumbled upon tlbimp.exe, which according to Microsoft:
The Type Library Importer converts the type definitions found within a COM type library into equivalent definitions in a common language runtime assembly. The output of Tlbimp.exe is a binary file (an assembly) that contains runtime metadata for the types defined within the original type library.
Okay. Well anyways, I opened a Visual Studio Developer Prompt (regular cmd doesn't have tlbimp.exe on the path), and ran my DLL through it. It created a new DLL, which I was able to add as a reference, and it satisfied my project dependencies. However, I haven't tested it just yet to make sure everything still works as it should once this thing is running, so I'll update with what I find there.
UPDATE
Yeah, so this doesn't work either. I get the same error once it's running saying that the class is not registered. Only now, I can't register this DLL because tlbimp.exe removes the entry-point.
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
I have upgraded a VB5 product to VB6 and produced an executable from the VB6 IDE. It will not execute properly without the presence of MSVBVM50.DLL. Without it it generates the following error:
Automation error - cannot find specified module.
What could the reason for this?
Is it possible that there is a component DLL that has been compiled in VB5 that would require the VB5 VM?
In the VB6 IDE the Project > Components menu will show the Components dialog and Project > References will show the References dialog.
Find which components are ticked and make sure that they are the VB6 versions and not VB5 versions. Many of the standard controls were updated with VB6.
In particular look for the various 'Microsoft windows Common Controls' entries as they are some of the ones you are least likely to notice changing as they are visually identical in the toolbox.
Your suggestion is correct. If you are using a component (DLL, OCX) that depends on the VB5 runtime you can't run your program without it.
You need to check your referenced DLL's and components to search for the one using VB5 VM.