I want to make a class in a shared OCX control have the same version as my application. Is there anyway to specify the version of a class in an OCX? In Windows registry the CLSID is surprising me with version numbers I never specified and never saw where they came from.
To make things more straightforward, see the highlighted parts in the screen shot below:
This is VB6 programming. Unfortunately or fortunately I need to work on this legacy code base and update bits and pieces (compiling new versions of the program). The control itself is compiled from source code as well. That's why I want to control the version of the class.
File version 1.03.0007 comes from file VERSIONINFO.
In VB6 you may specify this info:
Project->Properties->Make->Version Number
Version 2.1 is version of your control. Is used as identifier with
ProgID.
In VB6 you may specify this info:
Project->Properties->Component->Version Compatibility.
And select Project Compatibility radio button.
Related
I'd like to build a keyboard layout that runs on Win7 and later without using MSKLC.
I downloaded the Keyboard Layout Samples, and although it says it requires VS2013 Preview and WDK8.1 Preview, it builds using VS2012 and WDK8 after changing the "Platform Toolset" property from "WindowsApplicationForDrivers8.1" to "WindowsApplicationForDrivers8.0".
But: Checking the kbdus.dll built with Dependency Viewer reveals that it imports quite a lot of stuff from kernel32.dlland from msvcr110.dll. This is in contrast to kbdus.dll from the Windows\system32 directory, which, as one might expect, does not import anything and exports one single function.
My first question: Is it an issues that the dll built imports from msvcr110.dll?
I guess it is, as Win7 does not include this dll. (Honestly, I'm wondering how this can be, because these are official Microsoft samples.)
Tweaking around with compiler and linker settings, I managed to get rid of imports from msvcr110.dll, but the dll built still imports a lot of stuff and is quite large (> 70kB), compared to the original kbdus.dll (7kB). It's the same with x86 and x64, Debug and Release builds. I'm looking for the /compileandlinkanddonothingfancy switch.
My second question: How can these dlls be built correctly?
(Note: I found this question, but it is about WDK7. That will be what I try next, if I don't get it with WDK8.0)
I think one should pass /noentry to the linker.
I'm porting a project from MSVS2005 to MSVS2010. I just loaded the solution in MSVS2010 and let the wizard convert the projects.
I ran into the property manager and found these property sheets (top-to-bottom):
Upgrade from VC 7.1
Microsoft.Cpp.x64(or Win32).user
Multi-byte Character Support (not editable)
Dynamic Link to MFC (not editable)
I understand the last three ones but I don't know what is the purpose of Upgrade from VC 7.1. Can someone give me a little explanation?
P.S. I found C/C++, Preprocessor, Preprocessor Definitions = _VC80_UPGRADE=0x0710;%(PreprocessorDefinitions) in property page "Upgrade from VC 7.1" but in project properties I see NDEBUG;WIN32;_LIB;%(PreprocessorDefinitions). What does all this mean? What is the _VC80_UPGRADE=0x0710 macro?
A project property sheet simply pre-sets settings for a project. Unless the project overrides the setting. Which your project does, it overrides the "Preprocessor Definitions" setting. The extra "%(PreprocessorDefinitions)" macro ensures that the definitions from the property sheets are appended and not lost.
So the definitions that the compiler sees are NDEBUG;WIN32;_LIB;_VC80_UPGRADE=0x0710
The _VC80_UPGRADE macro helps your old project to compile and run correctly on Visual Studio version 2005 or later. It is used, for one, in vc/atlmfc/include/afxres.h to ensure that the manifest resource has the correct ID.
You are skipping many VS and Windows versions so this doesn't exactly mean you'll have no problems at all. Particularly UAC can give you a headache.
I built a VB Windows Forms application a while back using VS05 (or VS08? Not exactly sure) that I've recently converted to use VS10. I reference a .dll called ExcelPackage (another article, usage) so that I can create/manipulate Excel docs serverside. This app has worked fine on my old computer (PC/Vista) for a number of years. However, I have tried to move it to my new computer (PC/Win7 64-bit), and I can't get it to recognize the ExcelPackage .dll.
I have tried recompiling the .dll in VS10 and dropping the new .dll in my bin folder and re-referencing it. When I do this, before I try building, all my errors go away and I am actually able to navigate the class using VS10's built in ability (mouse over Imports OfficeOpenXml and you get a dropdown arrow that allows you to go through the classes). After I build, I get a green squiggly under my Imports OfficeOpenXml statement (can't find the reference).
I did some research and discovered that the .dll containing System.IO.Packaging has been moved around in .NET 3.0 and even re-referenced the new .dll, rebuilt, re-added, re-referenced, still no dice.
Am I missing something, or how do I get my application to recognize this assembly so that I can compile and continue working?
Thanks.
I don't see anything special about that project. Do note that the solution and project need to be converted. When that happens, you'll end up targeting the .NET 2.0 framework. That won't work out well, it has an assembly reference to WindowsBase, a 3.0 assembly. Make sure you update the target.
We have recently decided to start shipping the versions of some of the DLL files that a product requires with the product itself.
This is to guard against the situation where (for example) the MVC DLL file is updated on the server to which the software is deployed and the product fails to work as it was written against the now previous version of the DLL.
If the MVC DLL file of the specific version is included in the product and "locally" referenced this prevents this problem from happening. (In an ideal world every product which will be installed onto the destination server would be updated to the most recent version but this is not always practical)
My concern and question is whether this is going to give a false sense of security or not actually cope with the problem in the following situation: if Version 1.0 of the MVC DLL file is relying on method X of standard Microsoft DLL library Y and this DLL file Y is updated we will be in the same situation of having a broken product?
Assuming you meant the MSVC (Microsoft Visual C++) DLLs, the correct solution is to use an application manifest. The MSVC DLLs support Side by Side installation (SxS). This means that a new version of those DLLs does not replace an old version. Your application manifest tells Windows which DLL version(s) you want.
I don't know about MVC specifically, but you have a bigger problem if the conflicting version of a dependency dll is installed to the GAC on your target machine, as it will be used in preference to the local file.
Depending on how big it would make your final product, consider statically linking your program. This will prevent the much dreaded DLL hell since you wont have to give DLLs out.
We upgraded our machines with a microsoft patch listed above and are now having issues with some winsock controls. While moving on to the new component library there were two issues that we faced:
We are creating a Winsock control dynamically using Form.Controls.Add(...). With the new dlls it gave us a run time error 731 stating that we needed to add the license.
This issue was resolved by adding a line License.Add(PrgID of the control) before adding the control.
Now the issue is when we try setting this control to an object of type mWinsock we get a runtime error Type Mismatch. Any thoughts?
Take a look at "Description of the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files."
http://support.microsoft.com/kb/957924/
This December 30, 2008 update should remove and replace the faulty Dec 9 security update. It appears to deal with both 926857 and 957924.
958369 seems to be a Visual FoxPro KB article for the same faulty update (Dec 9). VFP uses many VB controls.
You may need to add the control to the toolbox so that the VB6 project and form has a proper reference to it. You will need to do this even if you don't actually have it on the form at design time.
With the reference VB may not have all the information needed to resolve the methods and properties of the control at run-time
Since the interface signatures have changed, you will have to remove the component reference from the project, save and close VB6 completely, unregister the old control, register the new version from the patch, reopen your project and add the component back in. If you do this you'll most likely lose support for machines that don't have the patch installed (or you will have to install it as part of your installation package)
Of course, you can always declare the reference "As Object" if it's easier but your performance will drop a bit and you will lose support for WithEvents
I encountered a similar issue when dynamically creating non-intrinsic controls in VB6. Perhaps Winsock is no longer considered intrinsic. Try declaring your variable as VBControlExtender instead of Winsock, as follows:
Option Explicit
Dim WithEvents objExt As VBControlExtender
Private Sub LoadControl()
Licenses.Add "MSWinsockLib.Winsock", "xydsfasfjewfe"
Set objExt = Controls.Add("MSWinsockLib.Winsock", "myCtl")
End Sub
Private Sub extObj_ObjectEvent(Info As EventInfo)
' Program the events of the control using Select Case.
Select Case Info.Name
Case "DataArrival"
' Do stuff
End Select
End Sub
See this MSDN article for more information.