Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, December 8, 2011 6:42 PM
Hello,
I have an issue with "mshtml.dll" library, I made some modifications (an upgrade) to an existing C# application (already deployed) and I added mshtml as a reference from ".NET" tab the "Microsoft.mshtml" (needed for new updates), the aplication works just fine in the developer PC.
I finished and tested the modifications and I deployed new updates to the existing PCs (via internet, I deployed the updates without the mshtml.dll), then I started to get errors from customer PCs: "mshtml.dll" is missing ... I found in some forums that there is a problem with this library somehow it depends in the version of the IE and I was suggested to add this file mshtml.dll as a part of the update, but it is a file of 8Mbs!!
Then I saw that it is also possible to add this file like a reference from COM tab "Microsoft HTML Object Library", and it is actually in other path location that the option from adding the reference from ".NET" tab.
The application is used from PCs that runs Windows Vista and other that runs Windows XP
Question:
What is better?:
To add the reference mshtml from ".NET" tab or from "COM" tab? What is the difference?
It would be better to add it as separated file to the update deployment (local dll)?
Like in this thread saids:
Kikeman Electric Systems Engineer
All replies (10)
Friday, December 9, 2011 1:13 AM ✅Answered
On 12/8/2011 5:29 PM, Kikeman wrote:
> My advise to you is that you had better test this on a Vista and XP
> machine before you do any deployment, because either one of two things
> are going to happen if not done correctly. Either IE is going to start
> crashing possibly or the .Net application trying to use the DLL may
> start crashing possibly if things are not right.
>
>
> I did test with XP and Vista before deployment, with vista works fine,
> but with XP it does not work, except the development computer that has
> XP but in other computer with XP I get:
Maybe the one you are using is the same version that's on the machine,
which is a stroke of luck for you.
>
> System.IO.FileNotFoundException: Could not load file or assembly'Microsoft.mshtml, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
> File name:'Microsoft.mshtml, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
>
> I have used it as COM and the same, it tells me that the file for XP is:
>
> C:\WINNT\assembly\GAC\Microsoft.mshtml\7.0.3300.0__b03f5f7f11d50a3a\Microsoft.mshtml.dll
>
> So that, what you are telling me is that it is not recommended to deploy
> one *mshtml.dll* because maybe the target computer may have another
> version of *mshtml.dll* in their system?
You had better find out what version of the COM DLL you are trying to
deploy against what version is already on the machine.
How do you know that a method in the DLL deploy is not in the DLL the
application is already using and is not there anymore in the one you
deployed? BOOM and down it goes?
> Even if I have the *mshtml.dll*
> in the application folder only, would I have some problems?
First off, you had better find out how to use that COM component in
.NET, which I don't think you have achieved. It may have changed between
different versions of VS, but you had better find out one way or another.
http://support.microsoft.com/kb/307367
From what I understand is that a true .NET DLL can be in the folder
with the application and .NET will find it. The .NET DLL doesn't have to
be registered with the O/S.
However, this may not apply to a COM DLL, and what I know about from the
past when I was a COM programmer is the COM DLL had to be registered
with the O/S so that it could be found and used by an application.
Only one version of the COM component can be registered and the path
established as to where that DLL is located. Now you register your COM
DLL that replaces the one that was previously registered and everything
was working with it. I can only guess what's going to happen, and it's
not going to be good.
Secondly, you should follow this thread.
<http://objectmix.com/dotnet/104492-how-ensure-microsoft-mshtml-deployement-machines.html>
And what you have done with Vista, I find suspect and may not be right.
All I am saying is that you had better make sure the T's are crossed and
the I's are dotted on this else all hell in going to break loose on this.
Now don't forget that Vista can be using IE 8 or IE 9 with a client you
have no control over what the client has on his or her machine. The same
holds true on IE on XP. Just because it works on your test machine Vista
or XP machine does it mean it's going to work on the client's machine.
If you did the deploy to client machines, you had total control of the
environment those machines were in and they match the basic setup of
your test machines, then you are probably going to be ok on the deploy.
But if that's not the case, then you may want to get testing coverage on
various setups with IE that you can test against. It's just a suggestion.
Friday, December 9, 2011 2:22 AM ✅Answered
On 12/8/2011 8:40 PM, Kikeman wrote:
> Ok, so, It looks that the correct way is to run "vs_piaredist.exe", I
> would be happy to do this if I can get rid of this problem, however, now
> the problem is that some target computers are used by persons that are
> not computer administrators, therefore they are not able to install
> "vs_piaredist.exe" ... because that computers already had installed the
> application, remember that I am just deploying updates of an existing
> application ...
>
> This is very bad situation ...
Your deployment set up should have that exe in the deploy package, the
deploy setup should be able to execute that exe and get results that
tells your deploy to proceed or terminate. The deploy should be using
the TrustedInstaller and the TrustedInstaller account on the machine,
which should have all the power and rights you need.
http://www.file.net/process/trustedinstaller.exe.html
Look up the TrustedInstaller and find out how to use it -- use Bing or
Google.
You may also want to lookup setting up a .NET deploy package, and there
are other install applications like Installsheld that may give you the
functionality you need.
Thursday, December 8, 2011 6:56 PM
On 12/8/2011 1:42 PM, Kikeman wrote:
>
> What is better?:
>
> To add the reference *mshtml* from ".NET" tab or from "COM" tab? *What
> is the difference?*
>
One sets reference to a .NET developed DLL, and the other one sets
reference to a legacy COM developed DLL. They are two different types of
development platforms that can create a DLL. .NET based component and a
COM based component from VS 6 C++ or even VB6 can create a COM based DLL.
You have to determine what kind of component/DLL you are working with,
becuase code to use a COM based component is different than using a .NET
based component in using a COM component in a .NET solution.
http://msdn.microsoft.com/en-us/magazine/cc301750.aspx
Thursday, December 8, 2011 8:26 PM
What I would like to do is to avoid including/sending 8Mb Library "mshtml" and use either .NET or COM but to be sure that the application is going to use the "mshtml" that is in the operative system (Vista or XP) once that the updates are sent to the customer computer.
Is it possible just to reference to the correct "mshtml" that is in the computer?
No matter if the application is running in Vista or XP?
So that, I can avoid sending this huge file to the customers and avoid including it to the installer of the application.
Kikeman Electric Systems Engineer
Thursday, December 8, 2011 9:15 PM
On 12/8/2011 3:26 PM, Kikeman wrote:
> What I would like to do is to avoid including/sending 8Mb Library
> "mshtml" and use either .NET or COM but to be sure that the application
> is going to use the "mshtml" that is in the operative system (Vista or
> XP) once that the updates are sent to the customer computer.
>
> Is it possible just to reference to the correct "mshtml" that is in the
> computer?
I say that the COM based component is already registered on the computer
due to IE being there, and that's the component you should be using the
component on the machine, unless the application I guess is using
elements that are not in the version that's already on the machine. Then
you would need to deploy the new COM based component.
>
> No matter if the application is running in Vista or XP?
>
> So that, I can avoid sending this huge file to the customers and avoid
> including it to the installer of the application.
http://msdn.microsoft.com/en-us/library/aa741312(v=vs.85).aspx
<copied>
Mshtml.dll is at the heart of Internet Explorer and takes care of its
HTML and Cascading Style Sheets (CSS) parsing and rendering
functionality. Mshtml.dll is sometimes referred to by its code name,
"Trident". Mshtml.dll exposes interfaces that enable you to host it as
an active document. Other applications such as Microsoft Word, Microsoft
Excel, Microsoft Visio, and many non-Microsoft applications also expose
active document interfaces so they can be hosted by shdocvw.dll. For
example, when a user browses from an HTML page to a Word document,
mshtml.dll is swapped out for the DLL provided by Word, which then
renders that document type. Mshtml.dll may be called upon to host other
components depending on the HTML document's content, such as scripting
engines (for example, Microsoft JScript or Visual Basic Scripting
Edition (VBScript)), ActiveX controls, XML data, and so on.
<end>
I can't tell you what to do. It's a COM based component I believe and
not a .NET component. A .NET component doesn't have to be resisted with
the O/S and many versions of the same named DLL can be in various
program directories used be a program accessing a particular directory
using its version of the DLL.
A COM based component like a DLL that last time I worked with a COM
based DLL has to be registered with the O/S. And only one version at a
time can be registered with the O/S.
Vista and XP are two different NT based O/S(s). Something that runs on
Vista is not guaranteed to run on XP. And something that runs on XP is
not guaranteed to run on Vista.
My advise to you is that you had better test this on a Vista and XP
machine before you do any deployment, because either one of two things
are going to happen if not done correctly. Either IE is going to start
crashing possibly or the .Net application trying to use the DLL may
start crashing possibly if things are not right.
There could be different versions of Mshtml.dll sitting on client
machines based on the version of IE that's on the client machine. You
could be creating a COM DLL hell issue for yourself if you have to
deploy and the wrong version DLL is deployed to the machine.
It might even comedown to what if IE 6, 7, 8 or 9 is on the client
machine with each IE using it's own version Mshtml.dll. What's going to
hapen if the wrong version of the DLL is deployed to the machine?
You had better stop, think and do your homework before this blows up in
your face. I have been there and done that with COM based components and
DLL hell issues. :)
Thursday, December 8, 2011 9:49 PM
On 12/8/2011 3:26 PM, Kikeman wrote:
<slight correction>
A .NET component doesn't have to be registered.
Thursday, December 8, 2011 10:29 PM
My advise to you is that you had better test this on a Vista and XP
machine before you do any deployment, because either one of two things
are going to happen if not done correctly. Either IE is going to start
crashing possibly or the .Net application trying to use the DLL may
start crashing possibly if things are not right.
I did test with XP and Vista before deployment, with vista works fine, but with XP it does not work, except the development computer that has XP but in other computer with XP I get:
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.mshtml, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.File name: 'Microsoft.mshtml, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
I have used it as COM and the same, it tells me that the file for XP is:
C:\WINNT\assembly\GAC\Microsoft.mshtml\7.0.3300.0__b03f5f7f11d50a3a\Microsoft.mshtml.dll
So that, what you are telling me is that it is not recommended to deploy one mshtml.dll because maybe the target computer may have another version of mshtml.dll in their system? Even if I have the mshtml.dll in the application folder only, would I have some problems?
Kikeman Electric Systems Engineer
Friday, December 9, 2011 12:46 AM
What I did is to download the "Microsoft Office 2010: Primary Interop Assemblies Redistributable" PIA in short
Downloaded from here:
http://www.microsoft.com/download/en/details.aspx?id=3508
And I didn't need to do nothing else ... the application started to work just fine in Windows XP ...
Is there some kind of "counter indication" of doing this?
actually I don't have Office 2010 and the application works ...
Kikeman Electric Systems Engineer
Friday, December 9, 2011 1:14 AM
On 12/8/2011 7:46 PM, Kikeman wrote:
> What I did is to download the "Microsoft Office 2010: Primary Interop
> Assemblies Redistributable" PIA in short
>
> Downloaded from here:
>
> http://www.microsoft.com/download/en/details.aspx?id=3508
>
> And I didn't need to do nothing else ... the application started to work
> just fine in Windows XP ...
>
> *Is there some kind of "counter indication" of doing this? *
>
> actually I don't have Office 2010 and the application works ...
>
See my other post.
Friday, December 9, 2011 1:40 AM
Ok, so, It looks that the correct way is to run "vs_piaredist.exe", I would be happy to do this if I can get rid of this problem, however, now the problem is that some target computers are used by persons that are not computer administrators, therefore they are not able to install "vs_piaredist.exe" ... because that computers already had installed the application, remember that I am just deploying updates of an existing application ...
This is very bad situation ...
Kikeman Electric Systems Engineer