How can I change the version number on a Visual FoxPro COM dll?
I've changed the version number here but apparently that only controls the file version number, not the COM Version Number.
I'm guessing this is not possible within VFP but maybe there's a way outside of VFP?
Related
My question is similar to others, but my particular nuance of this problem doesn't appear to have an answer I can find on here so far, so here goes. (edits in italics)
Our company has a deployed application written in VB6. Since VB6 development is no longer officially supported in Windows, our company made the decision to port our VB6 application to VB.NET.
(Prior to this edit, I had mentioned that the project was converted to VB.NET using VS 2015. This was incorrect, I discovered that my coworker had actually performed the conversion using VS 2008, and I was working on the 2008 project in 2015.)
So we are now working with the VB.NET conversion in VS2015. As many of us know, the VS 2008 converter does an incomplete job porting VB6 code to VB.NET code so there are many, many errors to sort through (as of this writing, all compile errors are fixed). In particular, though, I'm trying to open the various forms for the project in the Designer so I can see and work with them. The designer specifically is reporting the error:
Could not resolve mscorlib for target framework '.NETFramework,Version=v2.0'. This can happen if the target framework is not installed or if the framework moniker is incorrectly formatted.
I saw some mention of a 256 character limit on dependency paths. This dependency is met in my case. I have also confirmed that .NET Framework 2.0 is installed and active in my instance of Windows. I have seen the recommendation to upgrade the .NET Framework version as well, which was successful in itself but did not resolve this mscorlib issue.
Full call stack for this error follows:
at Microsoft.VisualStudio.Shell.Design.VsTargetFrameworkUniverse..ctor(IDesignTimeAssemblyLoader assemblyLoader, IVsDesignTimeAssemblyResolution projectAssemblyResolution, IVsSmartOpenScope dispenser)
at Microsoft.VisualStudio.Shell.Design.VsTargetFrameworkUniverse.GetUniverse(IDesignTimeAssemblyLoader assemblyLoader, IVsDesignTimeAssemblyResolution projectAssemblyResolution, IVsSmartOpenScope dispenser)
at Microsoft.VisualStudio.Shell.Design.VsTargetFrameworkProvider..ctor(IVsDesignTimeAssemblyResolution assemblyResolution, IDesignTimeAssemblyLoader assemblyLoader, TypeDescriptionProvider parentProvider, IVsSmartOpenScope openScope)
at Microsoft.VisualStudio.Design.VsTargetFrameworkProviderService.get_TargetFrameworkProvider()
at Microsoft.VisualStudio.Design.VsTargetFrameworkProviderService.GetProvider(Type type)
at System.ComponentModel.Design.Serialization.DesignerSerializationManager.GetType(String typeName)
at System.ComponentModel.Design.Serialization.DesignerSerializationManager.System.ComponentModel.Design.Serialization.IDesignerSerializationManager.GetType(String typeName)
at System.ComponentModel.Design.Serialization.TypeCodeDomSerializer.Deserialize(IDesignerSerializationManager manager, CodeTypeDeclaration declaration)
at System.ComponentModel.Design.Serialization.CodeDomDesignerLoader.PerformLoad(IDesignerSerializationManager manager)
at Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.PerformLoad(IDesignerSerializationManager serializationManager)
at Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.DeferredLoadHandler.Microsoft.VisualStudio.TextManager.Interop.IVsTextBufferDataEvents.OnLoadCompleted(Int32 fReload)
How can I gain the ability to view my project in the Designer?
As far as I know, opening VB6 files in VB.NET will not work. You will have to make modifications in Visual Studio 6.0 or re-write the application in VB.NET/C#.
Older versions of Visual Studio (until 2008) had some converters but they never really worked as expected.
You can take a look at Visual Basic Tools for Visual Studio, it "allows to work with classic VB workspaces and projects within Visual Studio.", this will allow you to modify the VB6 project in a newer version of Visual Studio but the code will remain VB6.
Regarding your exact issue, others have reported that the following worked for them:
Remove and add back project references that have warnings.
Rebuild the project
Remove and add back Microsoft.Office.Core
Good luck!
As someone who has converted a number of VB6 applications to VB.Net, I always advise a full rewrite. The languages are just too different. You waste far too much time trying to resolve issues of this type.
Better still, just leave the VB6 application running as is.
Microsoft's VB6 support statement
I am using VBA for Excel. My requirement is that the forms created in VBA shall communicate with external system over serial port of my system. For the same purpose, like we do in VB, I am tring to add MS Comm Control in VBA.
I am able to add MS Comm Control to control panel by selecting the same from Tools -> Additional Controls. However, when I try to place MSComm control on my form, it gives me following error.
The subject is not trusted for specified action.
Due to this, I am not able to place the control on my form and hence not able to use the same.
The same behaviour is observed for MS Winsock Control.
Found a similar question on stackoverflow: MSCOMM32.ocx usage causes Not Trusted Error without any concrete answer.
My installations are:
Win XP - SP3, MS Office 2010, VB6, MS VS 2010.
Legal use of VB6 controls in an Excel macro (or in any 3rd party program or programming language) is restricted. The only exceptions are when you have licensed Office Developer Edition (or in newer versions of Office the extra developer package that contains VSTO or equivalent) or if you are just creating them for use on the same machine that has VB6 installed.
But your problem is probably either related to Microsoft kill-bitting the OCX (which prevents use in IE, and maybe in Office?), or more likely that you are using 64-bit Excel (and thus 64-bit VBA).
I got similar problem but with MsWinSck.OCX. I fixed it by loading ActiveX Compatibility Manager from http://www.nirsoft.net/utils/acm.html and enable the OCX (Winsck.OCX) by selecting the OCX in the lines then click the green LED on the menu.
Hope this may help.
I'm developing a vb6 application that uses Microsoft office word.
each single word11,word12,word14 object libraries can make my application work. But How do I detect which version of Office is installed and thus which version of the "Microsoft Word Object Library" is available, and subsequently load it?
Note: I don't want to use .net because many of my clients do not want to install .netframework.
Generally:
Code to the lowest version of Word you plan to support or do version tests before invoking any methods/properties that might not be supported under all versions
You don't load a Word Object Library; you invoke an instance of Word and automate it. Windows figures out which version of Word to invoke if there are multiple versions; once you have a Word object, you can query its version for your version tests.
On my PPT FAQ site, there's some general information about this; the same code should work in VB6 with only minor alterations, if any.
Controlling Office Applications from PowerPoint (by Naresh Nichani and Brian Reilly)
http://www.pptfaq.com/FAQ00795_Controlling_Office_Applications_from_PowerPoint_-by_Naresh_Nichani_and_Brian_Reilly-.htm
Either use late binding (... As Object) or build against the earliest version you want to support. The object libraries are backwards compataible and COM handles the versioning so you will always get the latest version installed.
I'm facing problem while reference vb6 dll in .net project. When ever i refer a vb6 dll in .net project the interop dll is created with same version(1.2.0.0). Its creating problem for me as the setup used to deploy the application at client side does not replace the dll if the version is same as before. I want to change the version of the interop dll (created using vb6 dll). I read it cam done using tlbIMP but how to create tlb file for vb6 dll. Or is there is any other way to achieve this.
Thanks
Saurabh
Here's a small batch file we use to create our interop dll so it's strongly named:
sn.exe -i MichiganLTAP.pfx MagicContainerName
tlbimp.exe ourVb6.dll /out:Our.Strongnamed.Interop.dll /asmversion:7.1.0.0 /keycontainer:MagicContainerName /machine:X86 /namespace:Our.Strongnamed /verbose /sysarray
sn.exe -d MagicContainerName
The important switch from your perspective is: /asmversion:7.1.0.0
You should be able to set that to whatever you want. Check out the MSDN Library page for more info on the switches available.
It makes very little sense to make the version number of the interop library different from the version number of the type library that was created by VB6. There is a one-to-one mapping between what's in the interop library vs the code you wrote in VB6. The interop library simply contains IL declarations for the VB6 COM interfaces, there is no actual code. The CLR uses it to quickly generate the RCW for the interface.
Change the type library version number in VB6 with Project + Properties, Make tab, Version number. Major and minor is what counts. Do this only when you make a change in the publicly visible VB6 classes. Doing so is required btw, it avoids DLL Hell.
Assume all traces of Office 2003 will be removed from the computer.
UPDATE:
I understand that I will still be able to use .xls files. I'm asking about automating Excel through the COM interop from outside Excel. When I add a reference to Excel to a VB project, it gives me a different version of the dll for different versions of Excel. If a program was compiled with a reference to Office 2003's dll, will it need to be recompiled for Office 2007? Will the code need to be updated to use the new dll?
You should have no problem with your code breaking. In my past experiences, even though I referenced old versions of the Interop Assemblies, the newer version of Excel has been able to handle the calls.
Now the same can't be said for trying to use a newer version of the Interop Assemblies with an older version of Excel...
It would be very surprising if there were many breaking changes between the versions. As I understand it, Microsoft has a number of customers using Office, and they wouldn't like a large number of breaking changes.
In my opinion, the above is actually a valid way of analyzing many questions of this type: "Could x possibly happen" is aproximately equivalent to "what would happen to Microsoft if they did x". If the answer is "something really bad would happen", then chances are that Microsoft figured that out ahead of time.
Of course, this doesn't work 100%. "Could Microsoft ever remove Web Application Projects from Visual Studio 2005" is a counterexample.