In my VS2012 project with Internet Explorer 10 installed if I add a reference by going to the COM references and choose MSHTML then it gives me the version that is installed in the GAC which is an old 7.0.3300.0. If I actually look in system32 or sysWOW64 then the .dll tlb version is a much much newer version.
How should I develop against the newer version?
If I understand it correctly mshtml is installed with Internet Explorer so if my deployment machines have IE10 then I should have no problems right?
Can anyone guess why the GAC has the old version in it? I have just check 2 other Win 7 installs and it is the same. GAC is 7.0.3300.0 but elsewhere it matches the IE version.
EDIT: The other Win 7 machines all have VS installed. I just looked on another Win 7 and there is nothing in the GAC. Is VS2012 installing this in the GAC?
Update after Comment
It appears that there are a few questions about this. this reference from the comment also this question which Hans was also involved in. I also found this forum thread as well on the topic.
I still down know what I should be doing, but I can certainly simply follow like a sheep the instructions. I suppose I need to create a PIA that will allow me to call the newer methods (This fixes VS), but understand that if this code is used on a PC that does not have the compatible MSHTML / IE version then it will crash. (Same as the Office PIA and if you call for example an office 2013 method that does not exist on an Office 2010 installation.).
In my question I have linked to what are probably seen as the more correct answers to this issue.
If someone is looking for a quick and dirty solution then use late binding. I will explain specifically in my case what this means.
Dim div as HTMLDivElement
'make div something
div.getElementsByClassName 'this was not working!!!
This would not compile as the reference that Visual Studio is using is an old version.
So instead of follow the above because I only needed this a couple of times I changed the code to this.
Dim div as Object
'make div something
div.getElementsByClassName
Now Visual Studio will not have a problem with it. The problem you do face is that the final end user must have at lease a version of MSHTML (which is installed with Internet Explorer) that has this method or higher.
I hope this helps people who are still trying to work out what PIA's are and how they work in Visual Studio and MS environments.
Related
I've tried everything - I swear...
But now I am running out of ideas and need some expert help.
I've already been using Microsoft.Office.Interop.Excel in the past.
But now, something seems to have changed.
Whatever I am trying, I can't get rid of that dll-error:
System.InvalidCastException:
'Unable to cast COM object of type 'Microsoft.Office.Interop.Excel.ApplicationClass'
to interface type 'Microsoft.Office.Interop.Excel._Application'.
This operation failed because the QueryInterface call on the COM component for the
interface with IID '{000208D5-0000-0000-C000-000000000046}' failed due to the following error:
Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).'
MY ENVIRONMENT:
My VS version:
Microsoft Visual Studio Community 2022 (64-bit) - Current Version 17.4.4
Interop.Excel version and path:
Microsoft Excel 16.0 Object Library
C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Office.Interop.Excel\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll
Office:
I am using Office 365.
1. started from scratch
To exclude everything else, I've set up a completely new project with nothing in there apart from the using-directive. And... I get the same error (see screenshot: https://i.stack.imgur.com/ZZHFN.png).
2. added reference in different ways
I've added the reference from the COM list, but also tried to directly use the path - no difference.
checked the file location and version
The file is exactly where it should be.
I can't see any newer version of the DLL for download either.
updated to the latest .NET version
Nothing changed.
Do you have an idea how I could solve this error?
(Please be gracious with your answer - I had a few years programming break and am just starting up again...)
Have a good day!
Katrin
I don't have an off-the-shelf solution for this, but any problem in VS 2022 related to COM interop reeks of 32/64-bit issues. Here are some thoughts:
Are you using 32-bit office? Check: File => Account => About Excel, and see what it says in bold font at the top.
Are you building for AnyCpu, or are you targeting a specific architecture (x86/x64)?
You could also check the registry to see if your assembly is actually registered for the correct "bitness", i.e. the one matching Excel.
VS2022 defaults to 64-bit if you're building AnyCpu, as opposed to earlier (32-bit) versions of VS.
/Einar
Meanwhile, I switched to the NuGet package "ClosedXML", which works fine. This should work for others with the same problem too.
Hint: Before installing, check the hints on the ClosedXml Website. The installation doesn't work the usual way (FEB-23), but there's an easy solution.
I'm developing an application written in Visual Basic 6.0 that supports exporting listViews to Microsoft Excel documents. Everything works perfectly fine if a user has an older version of Microsoft Office installed.
Now I want to add support for users who only have Microsoft/Office 365 on their systems. I've googled my way into depression in the past couple of days because I don't know much (or anything really) about dll/ocx files or registries. I'm not even sure if something like this can even be done because VB6 is really old, as noted here.
I've tried using this approach, but it didn't help me.
Right now, I'm getting a 429 runtime error
ActiveX Component can't create object
on line
Set objExcel = CreateObject("Excel.Application")
I only have Microsoft 365 trial version (no older ones) installed on the system and have these two things checked in my references:
I've also tried searching for Excel.Application in the registry, as suggested here, but I can't find the path to the corresponding ActiveX file (which probably means it is not registered if I understand this correctly).
What can I do? Any help would be greatly appreciated.
Never mind, I found the answer myself. The problem was that I had older Office versions installed when I installed new 365 package and for some odd reason the .dll files for 365 version weren't registered. When I deleted those older versions all the working .dll files were gone with them.
I did a repair of the 365 installation and it's working perfectly now.
I have spent an incredible amount of time getting our product to run properly on customers' machines after we moved to Visual Studio 2015, and I still have one problem left to solve. The problem is that I can't get any of the C++ 2015 redistributables installers to work on 32-bit Windows 7 when it hasn't been patched (Windows Update).
The full story:
We upgraded all projects in the solution from VS 2013 to VS2015 and .NET 4.5.2, which also forced us to upgrade to "Microsoft Visual C++ 2015 Redistributable (x86/64) - 14.0.23506/23026)". We've done this kind of upgrade many times before, from VS2010 and up, and it never failed before.
23506 (for short) are the DLLs that accompany VS2015. We always found it easier to just XCOPY the DLLs into our installation folder. For some reason that doesn't work with the DLLs from VS2015 (23506). The program can't find them even when placed in the same folder as the executables. Why not?
Then I ran vcredist_xXX.exe that accompany VS2015, and the program runs fine.
But I want to XCOPY, so I discovered the download of 23026 from Microsoft, but there are no DLLs in there - only vc_redist.xXX.exe. Still, I copied the DLLs from somewhere in Windows - the paths to each DLL is listed in the registry. By the way, there are two extra DLLs installed that are not present in the folders in VS2015. "mfc140.dll" and "mfcm140.dll". Why?
But XCOPYing 23026 didn't work either, not even with the two extra DLLs. Running vc_redist.xXX.exe from 23026 worked fine.
Ok, problem solved, I thought. Using vc_redist.xXX.exe instead of XCOPYing. But no.
The final problem is that vc_redist.x86.exe (from 23026) and vcredist_x86.exe (from 23506) both fail when run on a 32-bit Windows 7 machine that hasn't been patched (Windows Update) at all after installation. For reasons I won't go into, that's the kind of machines we have to install our product on - unpatched 32-bit Windows 7 - no way around it. (The problem maybe exists on 64-bit unpatched Windows also, but I haven't got the time to find out.)
How do I get around this?
I am trying to link the C++ runtime statically and drop the DLLs alltogether, but it seems impossible when you have native C++ with C++ wrappers in a .NET project. This issue has already been reported by others, so no need to go into it here.
I have tried searching for DLLs to download, or a way to extract DLLs from the installer. Anyway, as mentioned above, I already tried just copying them from somewhere below C:\Windows. Doesn't work, so I doubt I can get some DLLs that will work. But again, why? If somebody can help me figure out this, it could be the perfect solution for our problem.
I have been thinking about finding the exact Windows patch(es) needed to get that installer - vc_redist.x86.exe - to work on those crappy machines. If it's just one or a handful of KBs that doesn't destabilize these machines, that would perhaps be acceptable.
A possibility that definitely should work is to downgrade the C++ projects to VS2013, which doesn't have this problem. I am really fed up of us always having to keep two versions of Visual Studio on our developer machines as a workaround for some silly problem, but if there's no other way, then so be it, even in 2016.
Found a quick and simple workaround. Turns out we only need to change the setting "Platform Toolset" to "Visual Studio 2013 (v120)" in all the C++ projects, in order to build with the good old DLLs that still work with XCOPY deployment. I was under the impression this setting would not go together with .NET 4.5.2, which we need, but it does. VS2013 will have to be installed along with VS2015, but we can live with that.
As stated, this is a workaround. It doesn't solve the actual problem stated in the title. But since I actually asked for a way around the problem, I'll close the issue with this answer.
As for the actual problem, if anyone is interested: I found some blog entries on the Visual C++ Team Blog - "Introducing the Universal CRT" and "The Great C Runtime (CRT) Refactoring". Where that leads, I'm not sure.
I was able to get this resolved on my local PC by following the updated step 6 on that article: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
Once you copy the 20 or so DLLS folder it still didn't work for me, I had to grab the ucrtbase.dll and ucrtbased.dll along with all the usual 140 (mfc, mfcm,vcruntime, msvcp) from my SysWOW64 folder and finally i'm able to launch this on a windows 7 pc without requiring to install any patches!
When I attempt to install Microsoft Visual C++ 2010 Redistributable I get the following error.
I have an updated msvcrt.dll to replace the current one with but every time I delete/replace the old dll windows re adds the old one into the system32 folder again.
It would be useful to know the OS version you are using. Could be Windows 2000 or XP (my guess from the screenshot, but could be over RDP as well).
When msvcrt.dll became a first-class citizen (i.e. a system DLL) some time during the lifetime of XP, some changes were also made to it. Incompatible changes, I should add. Example: if you built a program against the VS CRT in former times (e.g. using the WDK/DDK) you could rely on the fact that it works starting with the least common denominator of existing msvcrt.dll versions. However, at some point MS decided that programs built to target, say, XP could rely on the new functionality that was snuck into newer versions of msvcrt.dll. Hence the observed incompatibility.
One way to make it work could be to add a file msvcrt.dll.local in the same folder or - failing that - to create a shim that enforced your intended behavior. See here.
Got similar error. Fixed it by restarting the server before the install.
I have a set of Windows programs that is mostly created with VB6 and VC++ 6. Its installer is created using InstallShield.
A couple users have recently reported a problem trying to install it on Vista. It is complaining that "MDAC 2.6 Sp2 cannot be installed on this machine. MDAC 2.6 Sp2 requires any one of the following configurations", and then lists several OSes, Vista not among them.
A little googling shows that there's a bug in InstallShield's handling of MDAC - it shouldn't be checking for it on Vista, because there is no such thing as MDAC on Vista (there's a new thing - "Windows DAC").
I could make the change to my InstallShield project suggested on that page, but I am concerned about doing so, because I have no way to test it (this problem does not occur on all Vista machines, and I haven't been able to make it happen on any Vista machine I have access to).
However, after looking at Wikipedia's page on MDAC, I can't imagine why we would need it for our programs in the first place. We're not using any databases, at least not explictly (maybe some Microsoft component that we're using is using it, though?).
I was not the original author of the InstallShield project. I am beginning to suspect that MDAC might have been inadvertantly added to it, or perhaps advertantly but just as "uhhh, maybe we need that".
How can I explicitly tell whether my programs need MDAC or not? I can look at the references and such in the VB6 and VC++ projects; is there any way to tell from those whether I can safely remove MDAC from the InstallShield project? For example, perhaps there's a single MDAC reference which, if not present in my VB/VC++ projects, means that my programs definitely do not require MDAC?
Thanks in advance for any help.
I expect you are right, MDAC was probably included with the original InstallShield project configuration, and nobody has bothered to remove it.
On the VB6 side you should be able to tell if MDAC is being used by going into the "References" dialog (I think its in the Projects dropdown menu of the ide) and checking to see if there is anything in there to do with MDAC or MSAccess. I haven't worked with VB6 in a while, but the text should look something like "Microsoft ActiveX Data Objects 2.x Library".
I'm guessing it is less likely that it is being used On the C++ side, but you could try searching for keywords like msdado, mdac and msaccess to see if theres any sign of a #import on one of the mdac dlls.
When deploying to Windows XP and later there is no reason to include MDAC or Jet 4.0, since even XP RTM (gold) shipped with MDAC 2.7 as well as Jet 4.0.
Microsoft Data Access Components (MDAC) release history
How to obtain the latest service pack for the Microsoft Jet 4.0 Database Engine goes into more recent Jet history.
MDAC releases include compatibility typelibs for ADO, so even if your program was compiled against MDAC 2.6 it will actually use the latest ADO on a target machine. The real grief can come if the program early-binds to ADOX.
ADOX never shipped with appropriate compatibility interfaces, so programs should almost always use late binding with ADOX.
DAO is another issue, but (a.) nobody should really be using it anymore without a good excuse and (b.) it died at DAO 3.6 so there should be no compatibility issue as long as your programs were upgraded to 3.6 and Jet5x (Jet 4.0, Access 2000 format).
The story gets more complicated when deploying downlevel from XP of course.
Beginning I think with Windows XP Microsoft began including MDAC. However, in MDAC version 2.6 and later they no longer included the Jet 4.0 components. (Jet 4.0 SP8 can be found here)
If you are using Visual Fox Pro you need to install either the ODBC or OLEDB drivers depending on you code for that.
ODBC
OLEDB
All of these downloads depend on having at least MDAC 2.6 installed.