Forcing an application to load assemblies from a specific path

[Fernando Tubio]

I have a *third-party* .NET application that fails when executed in Windows
7 (so far I have only tried with the beta, although I expect it to be the
same with the RC). I have already determined the cause. The application uses
reflection to retrieve information for a method in one of the types in the
framework. In Windows 7, this type was changed to add an overload for this
particular method and as a result, the call to Type.GetMethod now fails with
"Ambiguous match found.". (Remember that this is not my application so I
can't change the fact that it calls the GetMethod overload that takes a
single string parameter with the method's name.)

I will ignore for the moment the fact that we appear to be back in DLL hell
considering that assemblies in Windows 7 maintain the same version number
even though they have breaking changes. To resolve the problem, I want to
configure the application to load the System.dll assembly from .NET 3.5 SP1
instead.

My first approach was to set up a DEVPATH to a private folder where I copied
the correct assembly from another machine and I was able to confirm that the
application is able to execute successfully using this version of
System.dll.

However, to use DEVPATH you must configure it at the machine.config level
and it has an impact on every .NET application in the system. Instead, I
want to configure just this application so that it loads its own private
System.dll. I tried with <assemblyBinding> and a <codeBase> pointing to a
private folder, but this seems to be ignored.

So the question is, how can I force the application to load System.dll from
a specific path?

Thanks,
Fernando

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Curt Hagenlocher]

There's a good lesson here about the dangers of reflecting against
assemblies not under your control! Not that this helps you any... Unless --
is the application signed? If not, or if you don't mind re-signing it
yourself, it may be simplest to ILDASM / patch / rebuild it.

In the Windows 7 build on my laptop (something post-RC), the assembly
version of mscorlib.dll is 2.0.50727.4918. The version on my Vista box is
2.0.50727.3053, so the versions differ only by build number. I don't think
it's possible to have two different builds of the same 2.0.50727 version
installed on the same computer.

If you provide a type name and method name, I'd be happy to check this Win7
build to see if it also has the added overload. If so, I would encourage you
to file a compatibility bug against Windows 7. You probably have to go to
the Connect site to do that.

Post by Fernando Tubio
I have a *third-party* .NET application that fails when executed in Windows
7 (so far I have only tried with the beta, although I expect it to be the
same with the RC). I have already determined the cause. The application uses
reflection to retrieve information for a method in one of the types in the
framework. In Windows 7, this type was changed to add an overload for this
particular method and as a result, the call to Type.GetMethod now fails with
"Ambiguous match found.". (Remember that this is not my application so I
can't change the fact that it calls the GetMethod overload that takes a
single string parameter with the method's name.)
I will ignore for the moment the fact that we appear to be back in DLL hell
considering that assemblies in Windows 7 maintain the same version number
even though they have breaking changes. To resolve the problem, I want to
configure the application to load the System.dll assembly from .NET 3.5 SP1
instead.
My first approach was to set up a DEVPATH to a private folder where I
copied the correct assembly from another machine and I was able to confirm
that the application is able to execute successfully using this version of
System.dll.
However, to use DEVPATH you must configure it at the machine.config level
and it has an impact on every .NET application in the system. Instead, I
want to configure just this application so that it loads its own private
System.dll. I tried with <assemblyBinding> and a <codeBase> pointing to a
private folder, but this seems to be ignored.
So the question is, how can I force the application to load System.dll from
a specific path?
Thanks,
Fernando
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

Hi Curt,

First, the good news is that thanks to your other message, I realized that
you can specify <developmentMode> at the application configuration level.
I'm not sure if this is new in Windows 7 or has been there all along.
Reading the documentation suggested that you could only specify this at the
machine.config level. For example, see

How to: Locate Assemblies by Using DEVPATH
http://msdn.microsoft.com/en-us/library/cskzh7h6.aspx

In any case, it appears to work (I need to test it more thoroughly to make
sure).

And yes, I have to agree with you comment about reflecting against
assemblies that are not under our control. However, I'm not sure that I
agree that it is not possible to have two different builds of an assembly
installed on the same computer. If they have different assembly versions,
you should be able to install both into the GAC. I thought that was the
whole point of side-by-side versioning in .NET. In this particular case, the
updated assemblies in Windows 7 are similar to a service pack. But I think
it's questionable to do this if you are going to have breaking changes such
as the one I describe.

Thanks again,
Fernando

----- Original Message -----
From: "Curt Hagenlocher" <***@HAGENLOCHER.ORG>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Sunday, May 24, 2009 8:27 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

Post by Curt Hagenlocher
There's a good lesson here about the dangers of reflecting against
assemblies not under your control! Not that this helps you any... Unless --
is the application signed? If not, or if you don't mind re-signing it
yourself, it may be simplest to ILDASM / patch / rebuild it.
In the Windows 7 build on my laptop (something post-RC), the assembly
version of mscorlib.dll is 2.0.50727.4918. The version on my Vista box is
2.0.50727.3053, so the versions differ only by build number. I don't think
it's possible to have two different builds of the same 2.0.50727 version
installed on the same computer.
If you provide a type name and method name, I'd be happy to check this Win7
build to see if it also has the added overload. If so, I would encourage you
to file a compatibility bug against Windows 7. You probably have to go to
the Connect site to do that.

Post by Fernando Tubio
I have a *third-party* .NET application that fails when executed in Windows
7 (so far I have only tried with the beta, although I expect it to be the
same with the RC). I have already determined the cause. The application uses
reflection to retrieve information for a method in one of the types in the
framework. In Windows 7, this type was changed to add an overload for this
particular method and as a result, the call to Type.GetMethod now fails with
"Ambiguous match found.". (Remember that this is not my application so I
can't change the fact that it calls the GetMethod overload that takes a
single string parameter with the method's name.)
I will ignore for the moment the fact that we appear to be back in DLL hell
considering that assemblies in Windows 7 maintain the same version number
even though they have breaking changes. To resolve the problem, I want to
configure the application to load the System.dll assembly from .NET 3.5 SP1
instead.
My first approach was to set up a DEVPATH to a private folder where I
copied the correct assembly from another machine and I was able to confirm
that the application is able to execute successfully using this version of
System.dll.
However, to use DEVPATH you must configure it at the machine.config level
and it has an impact on every .NET application in the system. Instead, I
want to configure just this application so that it loads its own private
System.dll. I tried with <assemblyBinding> and a <codeBase> pointing to a
private folder, but this seems to be ignored.
So the question is, how can I force the application to load System.dll from
a specific path?
Thanks,
Fernando
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Curt Hagenlocher]

Yes, but I mistakenly said "assembly version" in my original email when I
meant to say "assembly file version". It's the file version that differs,
and the file version is not used to resolve assemblies from the GAC. The
problem is that all of the CLR2 versions of mscorlib.dll and System.dll --
that is, .NET 2.0, 3.0, 3.5 and their various service packs and hotfixes --
they all have an assembly version of 2.0.0.0.

Post by Fernando Tubio
Hi Curt,
First, the good news is that thanks to your other message, I realized that
you can specify <developmentMode> at the application configuration level.
I'm not sure if this is new in Windows 7 or has been there all along.
Reading the documentation suggested that you could only specify this at the
machine.config level. For example, see
How to: Locate Assemblies by Using DEVPATH
http://msdn.microsoft.com/en-us/library/cskzh7h6.aspx
In any case, it appears to work (I need to test it more thoroughly to make
sure).
And yes, I have to agree with you comment about reflecting against
assemblies that are not under our control. However, I'm not sure that I
agree that it is not possible to have two different builds of an assembly
installed on the same computer. If they have different assembly versions,
you should be able to install both into the GAC. I thought that was the
whole point of side-by-side versioning in .NET. In this particular case, the
updated assemblies in Windows 7 are similar to a service pack. But I think
it's questionable to do this if you are going to have breaking changes such
as the one I describe.
Thanks again,
Fernando
----- Original Message ----- From: "Curt Hagenlocher" <
Sent: Sunday, May 24, 2009 8:27 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path
There's a good lesson here about the dangers of reflecting against

Post by Curt Hagenlocher
assemblies not under your control! Not that this helps you any... Unless --
is the application signed? If not, or if you don't mind re-signing it
yourself, it may be simplest to ILDASM / patch / rebuild it.
In the Windows 7 build on my laptop (something post-RC), the assembly
version of mscorlib.dll is 2.0.50727.4918. The version on my Vista box is
2.0.50727.3053, so the versions differ only by build number. I don't think
it's possible to have two different builds of the same 2.0.50727 version
installed on the same computer.
If you provide a type name and method name, I'd be happy to check this Win7
build to see if it also has the added overload. If so, I would encourage you
to file a compatibility bug against Windows 7. You probably have to go to
the Connect site to do that.
I have a *third-party* .NET application that fails when executed in

Post by Fernando Tubio
Windows
7 (so far I have only tried with the beta, although I expect it to be the
same with the RC). I have already determined the cause. The application uses
reflection to retrieve information for a method in one of the types in the
framework. In Windows 7, this type was changed to add an overload for this
particular method and as a result, the call to Type.GetMethod now fails with
"Ambiguous match found.". (Remember that this is not my application so I
can't change the fact that it calls the GetMethod overload that takes a
single string parameter with the method's name.)
I will ignore for the moment the fact that we appear to be back in DLL hell
considering that assemblies in Windows 7 maintain the same version number
even though they have breaking changes. To resolve the problem, I want to
configure the application to load the System.dll assembly from .NET 3.5 SP1
instead.
My first approach was to set up a DEVPATH to a private folder where I
copied the correct assembly from another machine and I was able to confirm
that the application is able to execute successfully using this version of
System.dll.
However, to use DEVPATH you must configure it at the machine.config level
and it has an impact on every .NET application in the system. Instead, I
want to configure just this application so that it loads its own private
System.dll. I tried with <assemblyBinding> and a <codeBase> pointing to a
private folder, but this seems to be ignored.
So the question is, how can I force the application to load System.dll from
a specific path?
Thanks,
Fernando
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

I think that we agree then. That's what I meant when I mentioned that this
was similar to a service pack. The file version is different and the
assembly version remains the same, so that the new assembly replaces the
previous assembly in the GAC. (Well, strictly speaking nothing is replaced
in Windows 7 but the effect is the same as if .NET 3.5 SP1 had been
installed and then replaced with a service pack).

Cheers,
Fernando

----- Original Message -----
From: "Curt Hagenlocher" <***@HAGENLOCHER.ORG>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Sunday, May 24, 2009 10:25 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

Post by Curt Hagenlocher
Yes, but I mistakenly said "assembly version" in my original email when I
meant to say "assembly file version". It's the file version that differs,
and the file version is not used to resolve assemblies from the GAC. The
problem is that all of the CLR2 versions of mscorlib.dll and System.dll --
that is, .NET 2.0, 3.0, 3.5 and their various service packs and hotfixes --
they all have an assembly version of 2.0.0.0.

Post by Fernando Tubio
Hi Curt,
First, the good news is that thanks to your other message, I realized that
you can specify <developmentMode> at the application configuration level.
I'm not sure if this is new in Windows 7 or has been there all along.
Reading the documentation suggested that you could only specify this at the
machine.config level. For example, see
How to: Locate Assemblies by Using DEVPATH
http://msdn.microsoft.com/en-us/library/cskzh7h6.aspx
In any case, it appears to work (I need to test it more thoroughly to make
sure).
And yes, I have to agree with you comment about reflecting against
assemblies that are not under our control. However, I'm not sure that I
agree that it is not possible to have two different builds of an assembly
installed on the same computer. If they have different assembly versions,
you should be able to install both into the GAC. I thought that was the
whole point of side-by-side versioning in .NET. In this particular case, the
updated assemblies in Windows 7 are similar to a service pack. But I think
it's questionable to do this if you are going to have breaking changes such
as the one I describe.
Thanks again,
Fernando
----- Original Message ----- From: "Curt Hagenlocher" <
Sent: Sunday, May 24, 2009 8:27 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path
There's a good lesson here about the dangers of reflecting against

Post by Curt Hagenlocher
assemblies not under your control! Not that this helps you any... Unless --
is the application signed? If not, or if you don't mind re-signing it
yourself, it may be simplest to ILDASM / patch / rebuild it.
In the Windows 7 build on my laptop (something post-RC), the assembly
version of mscorlib.dll is 2.0.50727.4918. The version on my Vista box is
2.0.50727.3053, so the versions differ only by build number. I don't think
it's possible to have two different builds of the same 2.0.50727 version
installed on the same computer.
If you provide a type name and method name, I'd be happy to check this Win7
build to see if it also has the added overload. If so, I would encourage you
to file a compatibility bug against Windows 7. You probably have to go to
the Connect site to do that.
I have a *third-party* .NET application that fails when executed in

Post by Fernando Tubio
Windows
7 (so far I have only tried with the beta, although I expect it to be the
same with the RC). I have already determined the cause. The application uses
reflection to retrieve information for a method in one of the types in the
framework. In Windows 7, this type was changed to add an overload for this
particular method and as a result, the call to Type.GetMethod now fails with
"Ambiguous match found.". (Remember that this is not my application so I
can't change the fact that it calls the GetMethod overload that takes a
single string parameter with the method's name.)
I will ignore for the moment the fact that we appear to be back in DLL hell
considering that assemblies in Windows 7 maintain the same version number
even though they have breaking changes. To resolve the problem, I want to
configure the application to load the System.dll assembly from .NET 3.5 SP1
instead.
My first approach was to set up a DEVPATH to a private folder where I
copied the correct assembly from another machine and I was able to confirm
that the application is able to execute successfully using this version of
System.dll.
However, to use DEVPATH you must configure it at the machine.config level
and it has an impact on every .NET application in the system. Instead, I
want to configure just this application so that it loads its own private
System.dll. I tried with <assemblyBinding> and a <codeBase> pointing to a
private folder, but this seems to be ignored.
So the question is, how can I force the application to load System.dll from
a specific path?
Thanks,
Fernando
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Trey Nash]

Hi Fernando,

Let's be careful about what we call a "breaking change". I don't know which
BCL type you are speaking of, but adding a method overload to a class is not
a breaking change since the type still implements the same contract that it
implemented previously. Therefore, it won't be breaking compatibility with
those that consume that contract.

I would point the finger at the 3rd party application in this case. I find
it odd that it relies upon reflection to call a method that was probably
statically known at compile time. Had the application done this, then there
would be no problem. Essentially, the application has deferred essential
work of the compiler to run time.

But again, not knowing the exact type and method you are referring to, it's
impossible to draw a 100% conclusion on where to put the blame.

-Trey


---------------------------------------
Trey Nash

Check out my book "Accelerated C# 2008"
http://www.amazon.com/Accelerated-C-2008-Trey-Nash/dp/1590598733

-----Original Message-----
From: Discussion of advanced .NET topics. [mailto:ADVANCED-
Sent: Sunday, May 24, 2009 8:11 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load
assemblies from a specific path
Hi Curt,
First, the good news is that thanks to your other message, I realized that
you can specify <developmentMode> at the application configuration level.
I'm not sure if this is new in Windows 7 or has been there all along.
Reading the documentation suggested that you could only specify this at the
machine.config level. For example, see
How to: Locate Assemblies by Using DEVPATH
http://msdn.microsoft.com/en-us/library/cskzh7h6.aspx
In any case, it appears to work (I need to test it more thoroughly to make
sure).
And yes, I have to agree with you comment about reflecting against
assemblies that are not under our control. However, I'm not sure that I
agree that it is not possible to have two different builds of an assembly
installed on the same computer. If they have different assembly versions,
you should be able to install both into the GAC. I thought that was the
whole point of side-by-side versioning in .NET. In this particular case, the
updated assemblies in Windows 7 are similar to a service pack. But I think
it's questionable to do this if you are going to have breaking changes such
as the one I describe.
Thanks again,
Fernando
----- Original Message -----
Sent: Sunday, May 24, 2009 8:27 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load
assemblies
from a specific path

Post by Curt Hagenlocher
There's a good lesson here about the dangers of reflecting against
assemblies not under your control! Not that this helps you any... Unless --
is the application signed? If not, or if you don't mind re-signing it
yourself, it may be simplest to ILDASM / patch / rebuild it.
In the Windows 7 build on my laptop (something post-RC), the assembly
version of mscorlib.dll is 2.0.50727.4918. The version on my Vista

box is

Post by Curt Hagenlocher
2.0.50727.3053, so the versions differ only by build number. I don't

think

Post by Curt Hagenlocher
it's possible to have two different builds of the same 2.0.50727

version

Post by Curt Hagenlocher
installed on the same computer.
If you provide a type name and method name, I'd be happy to check

this

Post by Curt Hagenlocher
Win7
build to see if it also has the added overload. If so, I would

encourage

Post by Curt Hagenlocher
you
to file a compatibility bug against Windows 7. You probably have to

go to

Post by Curt Hagenlocher
the Connect site to do that.

Post by Fernando Tubio
I have a *third-party* .NET application that fails when executed in Windows
7 (so far I have only tried with the beta, although I expect it to

be the

Post by Curt Hagenlocher

Post by Fernando Tubio
same with the RC). I have already determined the cause. The

application

Post by Curt Hagenlocher

Post by Fernando Tubio
uses
reflection to retrieve information for a method in one of the types

in

Post by Curt Hagenlocher

Post by Fernando Tubio
the
framework. In Windows 7, this type was changed to add an overload

for

Post by Curt Hagenlocher

Post by Fernando Tubio
this
particular method and as a result, the call to Type.GetMethod now

fails

Post by Curt Hagenlocher

Post by Fernando Tubio
with
"Ambiguous match found.". (Remember that this is not my application

so I

Post by Curt Hagenlocher

Post by Fernando Tubio
can't change the fact that it calls the GetMethod overload that

takes a

Post by Curt Hagenlocher

Post by Fernando Tubio
single string parameter with the method's name.)
I will ignore for the moment the fact that we appear to be back in

DLL

Post by Curt Hagenlocher

Post by Fernando Tubio
hell
considering that assemblies in Windows 7 maintain the same version

number

Post by Curt Hagenlocher

Post by Fernando Tubio
even though they have breaking changes. To resolve the problem, I

want to

Post by Curt Hagenlocher

Post by Fernando Tubio
configure the application to load the System.dll assembly from .NET

3.5

Post by Curt Hagenlocher

Post by Fernando Tubio
SP1
instead.
My first approach was to set up a DEVPATH to a private folder where

I

Post by Curt Hagenlocher

Post by Fernando Tubio
copied the correct assembly from another machine and I was able to confirm
that the application is able to execute successfully using this

version

Post by Curt Hagenlocher

Post by Fernando Tubio
of
System.dll.
However, to use DEVPATH you must configure it at the machine.config

level

Post by Curt Hagenlocher

Post by Fernando Tubio
and it has an impact on every .NET application in the system.

Instead, I

Post by Curt Hagenlocher

Post by Fernando Tubio
want to configure just this application so that it loads its own

private

Post by Curt Hagenlocher

Post by Fernando Tubio
System.dll. I tried with <assemblyBinding> and a <codeBase> pointing

to a

Post by Curt Hagenlocher

Post by Fernando Tubio
private folder, but this seems to be ignored.
So the question is, how can I force the application to load

System.dll

Post by Curt Hagenlocher

Post by Fernando Tubio
from
a specific path?
Thanks,
Fernando
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

Hi Trey,

Very well. I will try to be careful. :-)

My definition of "breaking change" is something that causes a working
application to fail when you install an updated version of one of its
dependencies. What you describe - preserving the contract - is only one
aspect of maintaining compatibility, albeit a very important one. I
completely agree that most applications would be unaffected as long as the
contract is maintained. But the fact remains that the application - since
you ask, it's the VMware vSphere client - runs correctly with version
2.0.0.XXXX of System.dll and yet fails when using 2.0.0.YYYY. Whether the
developers could have prevented this problem by not relying on reflection is
beside the point. The fact is that as a user, your application stops working
when you upgrade the system. And that is what I call a breaking change.

And as far as I know, you cannot install .NET 3.5 SP1 in Windows 7, so the
only option is to upgrade the application. In this case, I'm sure that there
will be an upgrade by the time Windows 7 is RTM but I'm a little bit
disappointed that this sort of thing still happens. After all, .NET was
supposed to insulate you from such changes through side by side versioning.

- Fernando


----- Original Message -----
From: "Trey Nash" <***@DIGITRIX.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 3:55 AM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

Post by Trey Nash
Hi Fernando,
Let's be careful about what we call a "breaking change". I don't know which
BCL type you are speaking of, but adding a method overload to a class is not
a breaking change since the type still implements the same contract that it
implemented previously. Therefore, it won't be breaking compatibility with
those that consume that contract.
I would point the finger at the 3rd party application in this case. I find
it odd that it relies upon reflection to call a method that was probably
statically known at compile time. Had the application done this, then there
would be no problem. Essentially, the application has deferred essential
work of the compiler to run time.
But again, not knowing the exact type and method you are referring to, it's
impossible to draw a 100% conclusion on where to put the blame.
-Trey
---------------------------------------
Trey Nash
Check out my book "Accelerated C# 2008"
http://www.amazon.com/Accelerated-C-2008-Trey-Nash/dp/1590598733

-----Original Message-----
From: Discussion of advanced .NET topics. [mailto:ADVANCED-
Sent: Sunday, May 24, 2009 8:11 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load
assemblies from a specific path
Hi Curt,
First, the good news is that thanks to your other message, I realized that
you can specify <developmentMode> at the application configuration level.
I'm not sure if this is new in Windows 7 or has been there all along.
Reading the documentation suggested that you could only specify this at the
machine.config level. For example, see
How to: Locate Assemblies by Using DEVPATH
http://msdn.microsoft.com/en-us/library/cskzh7h6.aspx
In any case, it appears to work (I need to test it more thoroughly to make
sure).
And yes, I have to agree with you comment about reflecting against
assemblies that are not under our control. However, I'm not sure that I
agree that it is not possible to have two different builds of an assembly
installed on the same computer. If they have different assembly versions,
you should be able to install both into the GAC. I thought that was the
whole point of side-by-side versioning in .NET. In this particular case, the
updated assemblies in Windows 7 are similar to a service pack. But I think
it's questionable to do this if you are going to have breaking changes such
as the one I describe.
Thanks again,
Fernando
----- Original Message -----
Sent: Sunday, May 24, 2009 8:27 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load
assemblies
from a specific path

Post by Curt Hagenlocher
There's a good lesson here about the dangers of reflecting against
assemblies not under your control! Not that this helps you any... Unless --
is the application signed? If not, or if you don't mind re-signing it
yourself, it may be simplest to ILDASM / patch / rebuild it.
In the Windows 7 build on my laptop (something post-RC), the assembly
version of mscorlib.dll is 2.0.50727.4918. The version on my Vista

box is

Post by Curt Hagenlocher
2.0.50727.3053, so the versions differ only by build number. I don't

think

Post by Curt Hagenlocher
it's possible to have two different builds of the same 2.0.50727

version

Post by Curt Hagenlocher
installed on the same computer.
If you provide a type name and method name, I'd be happy to check

this

Post by Curt Hagenlocher
Win7
build to see if it also has the added overload. If so, I would

encourage

Post by Curt Hagenlocher
you
to file a compatibility bug against Windows 7. You probably have to

go to

Post by Curt Hagenlocher
the Connect site to do that.

Post by Fernando Tubio
I have a *third-party* .NET application that fails when executed in Windows
7 (so far I have only tried with the beta, although I expect it to

be the

Post by Curt Hagenlocher

Post by Fernando Tubio
same with the RC). I have already determined the cause. The

application

Post by Curt Hagenlocher

Post by Fernando Tubio
uses
reflection to retrieve information for a method in one of the types

in

Post by Curt Hagenlocher

Post by Fernando Tubio
the
framework. In Windows 7, this type was changed to add an overload

for

Post by Curt Hagenlocher

Post by Fernando Tubio
this
particular method and as a result, the call to Type.GetMethod now

fails

Post by Curt Hagenlocher

Post by Fernando Tubio
with
"Ambiguous match found.". (Remember that this is not my application

so I

Post by Curt Hagenlocher

Post by Fernando Tubio
can't change the fact that it calls the GetMethod overload that

takes a

Post by Curt Hagenlocher

Post by Fernando Tubio
single string parameter with the method's name.)
I will ignore for the moment the fact that we appear to be back in

DLL

Post by Curt Hagenlocher

Post by Fernando Tubio
hell
considering that assemblies in Windows 7 maintain the same version

number

Post by Curt Hagenlocher

Post by Fernando Tubio
even though they have breaking changes. To resolve the problem, I

want to

Post by Curt Hagenlocher

Post by Fernando Tubio
configure the application to load the System.dll assembly from .NET

3.5

Post by Curt Hagenlocher

Post by Fernando Tubio
SP1
instead.
My first approach was to set up a DEVPATH to a private folder where

I

Post by Curt Hagenlocher

Post by Fernando Tubio
copied the correct assembly from another machine and I was able to confirm
that the application is able to execute successfully using this

version

Post by Curt Hagenlocher

Post by Fernando Tubio
of
System.dll.
However, to use DEVPATH you must configure it at the machine.config

level

Post by Curt Hagenlocher

Post by Fernando Tubio
and it has an impact on every .NET application in the system.

Instead, I

Post by Curt Hagenlocher

Post by Fernando Tubio
want to configure just this application so that it loads its own

private

Post by Curt Hagenlocher

Post by Fernando Tubio
System.dll. I tried with <assemblyBinding> and a <codeBase> pointing

to a

Post by Curt Hagenlocher

Post by Fernando Tubio
private folder, but this seems to be ignored.
So the question is, how can I force the application to load

System.dll

Post by Curt Hagenlocher

Post by Fernando Tubio
from
a specific path?
Thanks,
Fernando
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Curt Hagenlocher]

Also, http://geekswithblogs.net/akraus1/archive/2009/05/14/132125.aspx seems
to suggest a way to do the private DEVPATH thing.

Post by Fernando Tubio
I have a *third-party* .NET application that fails when executed in Windows
7 (so far I have only tried with the beta, although I expect it to be the
same with the RC). I have already determined the cause. The application uses
reflection to retrieve information for a method in one of the types in the
framework. In Windows 7, this type was changed to add an overload for this
particular method and as a result, the call to Type.GetMethod now fails with
"Ambiguous match found.". (Remember that this is not my application so I
can't change the fact that it calls the GetMethod overload that takes a
single string parameter with the method's name.)
I will ignore for the moment the fact that we appear to be back in DLL hell
considering that assemblies in Windows 7 maintain the same version number
even though they have breaking changes. To resolve the problem, I want to
configure the application to load the System.dll assembly from .NET 3.5 SP1
instead.
My first approach was to set up a DEVPATH to a private folder where I
copied the correct assembly from another machine and I was able to confirm
that the application is able to execute successfully using this version of
System.dll.
However, to use DEVPATH you must configure it at the machine.config level
and it has an impact on every .NET application in the system. Instead, I
want to configure just this application so that it loads its own private
System.dll. I tried with <assemblyBinding> and a <codeBase> pointing to a
private folder, but this seems to be ignored.
So the question is, how can I force the application to load System.dll from
a specific path?
Thanks,
Fernando
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Peter Ritchie]

Agreed. Just because the 3rd party code may be reflecting soley by method name (which will work if there are no overloads) does not make adding an overload a breaking change. For example, they're looking for trouble with code like this:

methodInfo =
typeof (FrameworkClass).GetMethod("Method", BindingFlags.Instance | BindingFlags.Public);

They should have something more like this:

methodInfo =
typeof (FrameworkClass).GetMethod("Method", BindingFlags.Instance | BindingFlags.Public, null, new Type[] {}, null);
There's all sorts of good reasons to reflect on types that could be staticall linked...

Can you detail what 3rd party application this is, so we can avoid using it?

-- Peter

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

I agree with everything you say as a developer. But how does this help an
end user? The application is still broken <=> breaking change.

- Fernando

----- Original Message -----
From: "Peter Ritchie" <***@PETERRITCHIE.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 11:21 AM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path


Agreed. Just because the 3rd party code may be reflecting soley by method
name (which will work if there are no overloads) does not make adding an
overload a breaking change. For example, they're looking for trouble with
code like this:

methodInfo =
typeof (FrameworkClass).GetMethod("Method", BindingFlags.Instance |
BindingFlags.Public);

They should have something more like this:

methodInfo =
typeof (FrameworkClass).GetMethod("Method", BindingFlags.Instance |
BindingFlags.Public, null, new Type[] {}, null);
There's all sorts of good reasons to reflect on types that could be
staticall linked...

Can you detail what 3rd party application this is, so we can avoid using it?

-- Peter

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Greg Young]

I could write code that used reflection to access a private field of a
framework object. If the internal implementation of that object changed but
the contract stayed the same would that be a breaking change?

My guess is you should file something with their support. There is always
virtual XP :)

Greg

Post by Fernando Tubio
I agree with everything you say as a developer. But how does this help an
end user? The application is still broken <=> breaking change.
- Fernando
----- Original Message ----- From: "Peter Ritchie" <
Sent: Tuesday, May 26, 2009 11:21 AM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path
Agreed. Just because the 3rd party code may be reflecting soley by method
name (which will work if there are no overloads) does not make adding an
overload a breaking change. For example, they're looking for trouble with
methodInfo =
typeof (FrameworkClass).GetMethod("Method", BindingFlags.Instance | BindingFlags.Public);
methodInfo =
typeof (FrameworkClass).GetMethod("Method", BindingFlags.Instance |
BindingFlags.Public, null, new Type[] {}, null);
There's all sorts of good reasons to reflect on types that could be staticall linked...
Can you detail what 3rd party application this is, so we can avoid using it?
-- Peter
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

[Peter Ritchie]

Programming "by coincidence" [1] should not put the onus on the framework to ensure all poorly written code works in a new framework.

If the framework designers thought like you, their only option would be to never add overloads; they'd have to always add only new method names. This would make for an entirely unusable framework over time. By the same logic, they wouldn't be able to add any methods with new names because someone my be relying on the null return from GetMethod, or relying on a specific array length from GetMethods.

That doesn't help the end-user; but realistically, poorly written code never does. The application developers have to accept the onus of writing good code for their users; something the framework designers have no control over.

If anything, the framework designers should deprecate GetMethod(string).

[1] http://www.pragprog.com/the-pragmatic-programmer/extracts/coincidence
===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Curt Hagenlocher]

On Tue, May 26, 2009 at 8:12 AM, Peter Ritchie <

Post by Peter Ritchie
If the framework designers thought like you, their only option would be to
never add overloads; they'd have to always add only new method names. This
would make for an entirely unusable framework over time.

I think we can all agree that the developer of the third-party application
has done something wrong here and that it should be possible to add
overloads to the core libraries in .NET. But we're not talking about a new
release of the framework or even a "service pack" -- it's "just a new build"
of the same version as what's already been released. They're usually a bit
more conservative than that over in building 42; my experience is that I
can't get any Reflection bugs fixed because "it might break existing
programs". :(

--
Curt Hagenlocher
***@hagenlocher.org

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

"If the framework designers thought like you, "...

Come on. You are being extremely unfair. I've already said that as a
developer I agreed with you. Let me quote this line from my original message
again.

..."Remember that this is not my application so I can't change the fact that
it calls the GetMethod overload that takes a single string parameter with
the method's name."...

I never said adding overloads was a bad thing. My only point was that it
broke applications and that I was disappointed that this wasn't handled
better with side by side versioning. Remember that for an end user - who
doesn't know what an overload is - the *only* option is to upgrade the
application. That is my only point.

- Fernando

----- Original Message -----
From: "Peter Ritchie" <***@PETERRITCHIE.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 12:12 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path


Programming "by coincidence" [1] should not put the onus on the framework to
ensure all poorly written code works in a new framework.

If the framework designers thought like you, their only option would be to
never add overloads; they'd have to always add only new method names. This
would make for an entirely unusable framework over time. By the same logic,
they wouldn't be able to add any methods with new names because someone my
be relying on the null return from GetMethod, or relying on a specific array
length from GetMethods.

That doesn't help the end-user; but realistically, poorly written code never
does. The application developers have to accept the onus of writing good
code for their users; something the framework designers have no control
over.

If anything, the framework designers should deprecate GetMethod(string).

[1] http://www.pragprog.com/the-pragmatic-programmer/extracts/coincidence
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Peter Ritchie]

Actually, this sort of thing is more common than not. When Vista was released it included a new version of the Framework (essentially an SP before it was available on prior versions of Windows). That version *did* have a breaking change.

On Tue, 26 May 2009 08:30:03 -0700, Curt Hagenlocher <***@HAGENLOCHER.ORG> wrote:

They're usually a bit

Post by Curt Hagenlocher
more conservative than that over in building 42; my experience is that I
can't get any Reflection bugs fixed because "it might break existing
programs". :(

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Peter Ritchie]

Post by Fernando Tubio
"If the framework designers thought like you, "...
Come on. You are being extremely unfair. I've already said that as a
developer I agreed with you. Let me quote this line from my original message
again.

By using wording like "breaking change" in the framework, and "how does this help an end-user" you're implying that the framework designers have done something wrong.

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

Not in the sense that their API is wrong. In other words, I'm not saying
that this is a problem of framework design. But yes, I do think that if
Windows 7 ships with .NET 3.5 SP1, then applications that previously worked
correctly with this version of the framework on other platforms should
continue to do so. I don't believe this to be an unreasonable expectation.
Do you?

----- Original Message -----
From: "Peter Ritchie" <***@PETERRITCHIE.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 12:53 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

Post by Fernando Tubio
"If the framework designers thought like you, "...
Come on. You are being extremely unfair. I've already said that as a
developer I agreed with you. Let me quote this line from my original message
again.

By using wording like "breaking change" in the framework, and "how does this
help an end-user" you're implying that the framework designers have done
something wrong.

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Peter Ritchie]

So, you're suggesting that the final version of the .NET framework that will ship with Windows 7 RTM should remove this new overload and add a method with a unique name?

Post by Fernando Tubio
Not in the sense that their API is wrong. In other words, I'm not saying
that this is a problem of framework design. But yes, I do think that if
Windows 7 ships with .NET 3.5 SP1, then applications that previously worked
correctly with this version of the framework on other platforms should
continue to do so. I don't believe this to be an unreasonable expectation.
Do you?
----- Original Message -----
Sent: Tuesday, May 26, 2009 12:53 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

Post by Fernando Tubio
"If the framework designers thought like you, "...
Come on. You are being extremely unfair. I've already said that as a
developer I agreed with you. Let me quote this line from my original
message
again.

By using wording like "breaking change" in the framework, and "how does this
help an end-user" you're implying that the framework designers have done
something wrong.
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives
===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

No, I'm leaving all the suggestions to you. I'm simply replying to your
objections to my use of the term "breaking change". If Windows 7 ships with
the framework and they call this .NET 3.5 SP1, and the application breaks,
then it is a breaking change.

Look, you are trying to push me into a side of the argument where I do not
wish to be. Whether MS is justified in introducing this change at the risk
of breaking some applications, I don't know. As I said previously, this is
really no different from DLL hell and I'm a little bit disappointed that
this is not handled better. After all, this is one of the issues that .NET
was supposed to address.

- Fernando

----- Original Message -----
From: "Peter Ritchie" <***@PETERRITCHIE.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 1:13 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path


So, you're suggesting that the final version of the .NET framework that will
ship with Windows 7 RTM should remove this new overload and add a method
with a unique name?

Post by Fernando Tubio
Not in the sense that their API is wrong. In other words, I'm not saying
that this is a problem of framework design. But yes, I do think that if
Windows 7 ships with .NET 3.5 SP1, then applications that previously worked
correctly with this version of the framework on other platforms should
continue to do so. I don't believe this to be an unreasonable expectation.
Do you?
----- Original Message -----
From: "Peter Ritchie"
Sent: Tuesday, May 26, 2009 12:53 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

Post by Fernando Tubio
"If the framework designers thought like you, "...
Come on. You are being extremely unfair. I've already said that as a
developer I agreed with you. Let me quote this line from my original
message
again.

By using wording like "breaking change" in the framework, and "how does this
help an end-user" you're implying that the framework designers have done
something wrong.
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Ryan Heath]

Terminology aside, I think from a end-user perspective it is hard to explain
that apparently .NET 3.5 SP1(Vista) is not equal to .NET 3.5 SP1(Win7) since
this app would run on .NET 3.5 SP1(Vista) but not on .NET 3.5
SP1(Win7).End-users
see the similar framework version and assume it has to work but we, as devs,
know their builds numbers are not the same and that one *can* run into
problems like these.
// Ryan

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Frans Bouma]

Post by Ryan Heath
Terminology aside, I think from a end-user perspective it is hard to explain
that apparently .NET 3.5 SP1(Vista) is not equal to .NET 3.5 SP1(Win7) since
this app would run on .NET 3.5 SP1(Vista) but not on .NET 3.5

SP1(Win7).End-

Post by Ryan Heath
users see the similar framework version and assume it has to work but we,

as

Post by Ryan Heath
devs, know their builds numbers are not the same and that one *can* run

into

Post by Ryan Heath
problems like these.
// Ryan

exactly.

for breaking changes, developers and ISV's should use the major and
minor version number. If these are the same, the build should be considered
the same.

FB

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Per Bolmstedt]

If Windows 7 ships with the framework and they call this .NET
3.5 SP1, and the application breaks, then it is a breaking change.

Well, since you are alone so far in your definition of the term "breaking change"; what changes would you consider to be *non-breaking* in the BCL without changing the assembly version?

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

I was not aware that the term "breaking change" had such specific semantics
that you were not allowed to use it in reference to an application that
ceases to function when a new build of an assembly is introduced. I'm sorry.
I won't do it again. From now on, I will refer to this as "disruptive
alteration" instead.

Do you know if Microsoft has published a list of "disruptive alterations" in
Windows 7 yet? ;-)

- Fernando

P.S. I'm very intrigued why everyone is so upset about my use of the term
"breaking change" to describe something that *breaks* as a result of a
*change* in the framework. Is it because the application deserved to be
broken? No need to answer this. I'm just "reflecting" to myself.

----- Original Message -----
From: "Per Bolmstedt" <***@UL7.INFO>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 2:18 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

If Windows 7 ships with the framework and they call this .NET
3.5 SP1, and the application breaks, then it is a breaking change.

Well, since you are alone so far in your definition of the term "breaking
change"; what changes would you consider to be *non-breaking* in the BCL
without changing the assembly version?

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Greg Young]

Fernando,

Perhaps you can explain which "disruptive alterations" should be considered
"breaking changes"?

What if my code depends on the # of bytes of IL in System.Xml? is ithis a
disruptive alteration?
What if my code takes a dependency on internal state of a framework object
is this a disruptive alteration?
What if my code calls private methods of an object in the framework is this
a disruptive alternation?
What if my code takes a dependency on the number of types in an assembly is
this a disruptive alteration?
What if my code depends on floating points always being truncated to 64bits
as opposed to being left in registers at 80 bits? Many found the problem to
this one at 2.0
What if my code depended on explicit interfaces being broken?
http://codebetter.com/blogs/gregyoung/archive/2006/09/02/Interface-Re_2D00_Implementation-bug-in-2.0-runtime.aspx

OK maybe that last one really is a breaking change but it agrees with the
spec so who wins?

I can play this game all day. You can't call these things breaking changes
because your definition of broken is well broken.

Post by Fernando Tubio
I was not aware that the term "breaking change" had such specific semantics
that you were not allowed to use it in reference to an application that
ceases to function when a new build of an assembly is introduced. I'm sorry.
I won't do it again. From now on, I will refer to this as "disruptive
alteration" instead.
Do you know if Microsoft has published a list of "disruptive alterations" in
Windows 7 yet? ;-)
- Fernando
P.S. I'm very intrigued why everyone is so upset about my use of the term
"breaking change" to describe something that *breaks* as a result of a
*change* in the framework. Is it because the application deserved to be
broken? No need to answer this. I'm just "reflecting" to myself.
UL7.INFO>
Sent: Tuesday, May 26, 2009 2:18 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path
If Windows 7 ships with the framework and they call this .NET

3.5 SP1, and the application breaks, then it is a breaking change.

Well, since you are alone so far in your definition of the term "breaking
change"; what changes would you consider to be *non-breaking* in the BCL
without changing the assembly version?
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

[Trey Nash]

LOL..... I was not upset about the phrase "breaking change". I was just
trying to be helpful and point out that, from a contractual standpoint,
which is really what should matter most, this is not a "breaking change".

I had no idea a religious war would ensue. :-)

Thanks,

-Trey

---------------------------------------
Trey Nash

Check out my book "Accelerated C# 2008"
http://www.amazon.com/Accelerated-C-2008-Trey-Nash/dp/1590598733

-----Original Message-----
From: Discussion of advanced .NET topics. [mailto:ADVANCED-
Sent: Tuesday, May 26, 2009 2:45 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load
assemblies from a specific path
I was not aware that the term "breaking change" had such specific semantics
that you were not allowed to use it in reference to an application that
ceases to function when a new build of an assembly is introduced. I'm sorry.
I won't do it again. From now on, I will refer to this as "disruptive
alteration" instead.
Do you know if Microsoft has published a list of "disruptive
alterations" in
Windows 7 yet? ;-)
- Fernando
P.S. I'm very intrigued why everyone is so upset about my use of the term
"breaking change" to describe something that *breaks* as a result of a
*change* in the framework. Is it because the application deserved to be
broken? No need to answer this. I'm just "reflecting" to myself.
----- Original Message -----
Sent: Tuesday, May 26, 2009 2:18 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load
assemblies
from a specific path

If Windows 7 ships with the framework and they call this .NET
3.5 SP1, and the application breaks, then it is a breaking change.

Well, since you are alone so far in your definition of the term "breaking
change"; what changes would you consider to be *non-breaking* in the BCL
without changing the assembly version?
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Brady Kelly]

Post by Trey Nash
I had no idea a religious war would ensue. :-)

Not religious, legal. :-) (w.r.t. 'language lawyers')

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Peter Ritchie]

The problem is you haven't picked a side. You've said you think the framework shouldn't break any software that runs on the previous version as well as saying their API is not wrong.

Do you see the contradiction in this? If the API isn't wrong and doesn't need changing, how do they "fix" the framework so it doesn't break this poorly coded application in the RTM version?

The interface contracts and the semantics of the framework are what the .NET framework is supposed to address with regard to "DLL hell". Even then, it's only as good at this as the designer of the framework. If the designer removes methods, properties or even classes; you're right back to DLL hell.

There's really nothing anyone can do to avoid breaking an application that is making incorrect assumptions while reflecting code. GetMethod("MethodName", BindingFlags.Instance | BindingFlags.Public) is one example--avoiding breaking this means never adding overloads to the framework. Another example is typeof(String).GetField("m_arrayLength", BindingFlags.NonPublic | BindingFlags.Instance)--avoiding breaking this means never changing or removing private fields. There's endless examples like this that eventually lead you to the only solution to making sure existing applications don't break with a new version of the framework is to never change the framework.

-- Peter

Post by Fernando Tubio
No, I'm leaving all the suggestions to you. I'm simply replying to your
objections to my use of the term "breaking change". If Windows 7 ships with
the framework and they call this .NET 3.5 SP1, and the application breaks,
then it is a breaking change.
Look, you are trying to push me into a side of the argument where I do not
wish to be. Whether MS is justified in introducing this change at the risk
of breaking some applications, I don't know. As I said previously, this is
really no different from DLL hell and I'm a little bit disappointed that
this is not handled better. After all, this is one of the issues that .NET
was supposed to address.

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

Finally! You seem to agree with me

... "There's really nothing anyone can do to avoid breaking an application
that is making incorrect assumptions while reflecting code."...

So it is a breaking change, sorry, a "disruptive alteration".

I insist that you are trying to push me into an API discussion when I
believe this is a deployment issue, and a very difficult one. I think they
can fix all the APIs that they want, and I'm glad that this happens. I'm not
convinced that claiming that this is still .NET 3.5 SP1 is the way to go.
And if Windows 7 introduces changes that can potentially disrupt
applications, then you should still be able to deploy the original
framework bits side by side and get on with your life. But I'm sure that
there are a lot more issues to consider other than maintaining compatibility
with a badly written application. Perhaps this is the reason why I'm
reluctant to "pick a side". That, and the fact that if you look at the
subject line, you will recall what my primary concern was. Certainly not
argueing for the inmutability of the framework APIs or the bad use of
reflection.

- Fernando

----- Original Message -----
From: "Peter Ritchie" <***@PETERRITCHIE.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 2:24 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path


The problem is you haven't picked a side. You've said you think the
framework shouldn't break any software that runs on the previous version as
well as saying their API is not wrong.

Do you see the contradiction in this? If the API isn't wrong and doesn't
need changing, how do they "fix" the framework so it doesn't break this
poorly coded application in the RTM version?

The interface contracts and the semantics of the framework are what the .NET
framework is supposed to address with regard to "DLL hell". Even then, it's
only as good at this as the designer of the framework. If the designer
removes methods, properties or even classes; you're right back to DLL hell.

There's really nothing anyone can do to avoid breaking an application that
is making incorrect assumptions while reflecting code.
GetMethod("MethodName", BindingFlags.Instance | BindingFlags.Public) is one
example--avoiding breaking this means never adding overloads to the
framework. Another example is typeof(String).GetField("m_arrayLength",
BindingFlags.NonPublic | BindingFlags.Instance)--avoiding breaking this
means never changing or removing private fields. There's endless examples
like this that eventually lead you to the only solution to making sure
existing applications don't break with a new version of the framework is to
never change the framework.

-- Peter

Post by Fernando Tubio
No, I'm leaving all the suggestions to you. I'm simply replying to your
objections to my use of the term "breaking change". If Windows 7 ships with
the framework and they call this .NET 3.5 SP1, and the application breaks,
then it is a breaking change.
Look, you are trying to push me into a side of the argument where I do not
wish to be. Whether MS is justified in introducing this change at the risk
of breaking some applications, I don't know. As I said previously, this is
really no different from DLL hell and I'm a little bit disappointed that
this is not handled better. After all, this is one of the issues that .NET
was supposed to address.

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Greg Young]

By your logic no bug could ever be fixed in a version and all releases would
have to be side by side.

I would have to run with the exact version I compiled against ...

Sounds familiar.

Post by Fernando Tubio
Finally! You seem to agree with me
... "There's really nothing anyone can do to avoid breaking an application
that is making incorrect assumptions while reflecting code."...
So it is a breaking change, sorry, a "disruptive alteration".
I insist that you are trying to push me into an API discussion when I
believe this is a deployment issue, and a very difficult one. I think they
can fix all the APIs that they want, and I'm glad that this happens. I'm not
convinced that claiming that this is still .NET 3.5 SP1 is the way to go.
And if Windows 7 introduces changes that can potentially disrupt
applications, then you should still be able to deploy the original
framework bits side by side and get on with your life. But I'm sure that
there are a lot more issues to consider other than maintaining
compatibility
with a badly written application. Perhaps this is the reason why I'm
reluctant to "pick a side". That, and the fact that if you look at the
subject line, you will recall what my primary concern was. Certainly not
argueing for the inmutability of the framework APIs or the bad use of
reflection.
- Fernando
----- Original Message ----- From: "Peter Ritchie" <
Sent: Tuesday, May 26, 2009 2:24 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path
The problem is you haven't picked a side. You've said you think the
framework shouldn't break any software that runs on the previous version as
well as saying their API is not wrong.
Do you see the contradiction in this? If the API isn't wrong and doesn't
need changing, how do they "fix" the framework so it doesn't break this
poorly coded application in the RTM version?
The interface contracts and the semantics of the framework are what the .NET
framework is supposed to address with regard to "DLL hell". Even then, it's
only as good at this as the designer of the framework. If the designer
removes methods, properties or even classes; you're right back to DLL hell.
There's really nothing anyone can do to avoid breaking an application that
is making incorrect assumptions while reflecting code.
GetMethod("MethodName", BindingFlags.Instance | BindingFlags.Public) is one
example--avoiding breaking this means never adding overloads to the
framework. Another example is typeof(String).GetField("m_arrayLength",
BindingFlags.NonPublic | BindingFlags.Instance)--avoiding breaking this
means never changing or removing private fields. There's endless examples
like this that eventually lead you to the only solution to making sure
existing applications don't break with a new version of the framework is to
never change the framework.
-- Peter
No, I'm leaving all the suggestions to you. I'm simply replying to your

Post by Fernando Tubio
objections to my use of the term "breaking change". If Windows 7 ships with
the framework and they call this .NET 3.5 SP1, and the application breaks,
then it is a breaking change.
Look, you are trying to push me into a side of the argument where I do not
wish to be. Whether MS is justified in introducing this change at the risk
of breaking some applications, I don't know. As I said previously, this is
really no different from DLL hell and I'm a little bit disappointed that
this is not handled better. After all, this is one of the issues that .NET
was supposed to address.

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

[Marc Brooks]

Post by Greg Young
By your logic no bug could ever be fixed in a version and all releases would
have to be side by side.

That's the Wii or PS3 OS model as I recall... No changes, just new
versions of the OS that you opt-into when you code a new game. Of
course that means that old applications never get the security or bug
fixes.

[Fernando Tubio]

Post by Greg Young
I would have to run with the exact version I compiled against ...
Sounds familiar.

Maybe it sounds familiar because it is the very definition of side-by-side
execution in .NET. It shouldn't matter whether another version fixes a bug.
You still have the choice to run against the version that you compiled
against and that *works*. This is what is missing here.

----- Original Message -----
From: "Greg Young" <***@GMAIL.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 4:59 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

Post by Greg Young
By your logic no bug could ever be fixed in a version and all releases would
have to be side by side.
I would have to run with the exact version I compiled against ...
Sounds familiar.

Post by Fernando Tubio
Finally! You seem to agree with me
... "There's really nothing anyone can do to avoid breaking an application
that is making incorrect assumptions while reflecting code."...
So it is a breaking change, sorry, a "disruptive alteration".
I insist that you are trying to push me into an API discussion when I
believe this is a deployment issue, and a very difficult one. I think they
can fix all the APIs that they want, and I'm glad that this happens. I'm not
convinced that claiming that this is still .NET 3.5 SP1 is the way to go.
And if Windows 7 introduces changes that can potentially disrupt
applications, then you should still be able to deploy the original
framework bits side by side and get on with your life. But I'm sure that
there are a lot more issues to consider other than maintaining compatibility
with a badly written application. Perhaps this is the reason why I'm
reluctant to "pick a side". That, and the fact that if you look at the
subject line, you will recall what my primary concern was. Certainly not
argueing for the inmutability of the framework APIs or the bad use of
reflection.
- Fernando
----- Original Message ----- From: "Peter Ritchie" <
Sent: Tuesday, May 26, 2009 2:24 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path
The problem is you haven't picked a side. You've said you think the
framework shouldn't break any software that runs on the previous version as
well as saying their API is not wrong.
Do you see the contradiction in this? If the API isn't wrong and doesn't
need changing, how do they "fix" the framework so it doesn't break this
poorly coded application in the RTM version?
The interface contracts and the semantics of the framework are what the .NET
framework is supposed to address with regard to "DLL hell". Even then, it's
only as good at this as the designer of the framework. If the designer
removes methods, properties or even classes; you're right back to DLL hell.
There's really nothing anyone can do to avoid breaking an application that
is making incorrect assumptions while reflecting code.
GetMethod("MethodName", BindingFlags.Instance | BindingFlags.Public) is one
example--avoiding breaking this means never adding overloads to the
framework. Another example is typeof(String).GetField("m_arrayLength",
BindingFlags.NonPublic | BindingFlags.Instance)--avoiding breaking this
means never changing or removing private fields. There's endless examples
like this that eventually lead you to the only solution to making sure
existing applications don't break with a new version of the framework is to
never change the framework.
-- Peter
No, I'm leaving all the suggestions to you. I'm simply replying to your

Post by Fernando Tubio
objections to my use of the term "breaking change". If Windows 7 ships with
the framework and they call this .NET 3.5 SP1, and the application breaks,
then it is a breaking change.
Look, you are trying to push me into a side of the argument where I do not
wish to be. Whether MS is justified in introducing this change at the risk
of breaking some applications, I don't know. As I said previously, this is
really no different from DLL hell and I'm a little bit disappointed that
this is not handled better. After all, this is one of the issues that .NET
was supposed to address.

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

--
It is the mark of an educated mind to be able to entertain a thought without
accepting it.
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Marc Brooks]

Post by Fernando Tubio
Finally! You seem to agree with me
... "There's really nothing anyone can do to avoid breaking an application
that is making incorrect assumptions while reflecting code."...
So it is a breaking change, sorry, a "disruptive alteration".

You're missing the point. If _YOU_ make _incorrect assumptions_ then
the break is on YOUR end. Nothing Microsoft can do will guarantee
no-breaking-changes (short of _no changes).

If you code incorrectly when doing reflection, you get what you
deserve. Just like the good old days when people made assumptions
about ISR vectors.

[Fernando Tubio]

Sorry, but I think you are missing the point. I_DID_NOT_ make
_any_incorrect assumptions. I only upgraded my OS to Windows 7. I did not
write the application. You are argueing from the point of view of a
developer while I'm argueing as an end user. But look at the facts.

Did the application work in Vista? Yes.
Does the application work in Windows 7? No.
Can you do anything to fix it? No, other than DEVPATH hacks.
Is it the fault of the application? Of course.

And I think this last point is what gets everyone upset. But from the
perspective of an end user, does it matter? As a user, I want the
application to run, not find someone to blame.

I find it disturbing that everyone is assuming that my belief is that bad
coding shouldn't get you into trouble. What I expect is that .NET
applications should provide a certain degree of insulation from the
underlying platform, and when a bad application comes along, the user should
be able to install the version of the framework that was used to compile the
application and run it. That is all.

----- Original Message -----
From: "Marc Brooks" <***@GMAIL.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 5:39 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

Post by Marc Brooks

Post by Fernando Tubio
Finally! You seem to agree with me
... "There's really nothing anyone can do to avoid breaking an application
that is making incorrect assumptions while reflecting code."...
So it is a breaking change, sorry, a "disruptive alteration".

You're missing the point. If _YOU_ make _incorrect assumptions_ then
the break is on YOUR end. Nothing Microsoft can do will guarantee
no-breaking-changes (short of _no changes).
If you code incorrectly when doing reflection, you get what you
deserve. Just like the good old days when people made assumptions
about ISR vectors.
--
Marc C. Brooks
http://musingmarc.blogspot.com
NOT sent from an iPhone
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Marc Brooks]

Post by Fernando Tubio
Did the application work in Vista? Yes.
Does the application work in Windows 7? No.
Can you do anything to fix it? No, other than DEVPATH hacks.
Is it the fault of the application? Of course.

And it is NOT a solvable problem _for Microsoft_. The only way we get
rid of bad programs is to get rid of bad programmers. Vote with your
feet and get away from that product.

Post by Fernando Tubio
And I think this last point is what gets everyone upset. But from the
perspective of an end user, does it matter?

It should. You don't sue General Motors when your car dies because
someone at the local gas station put diesel in the gas tank. The
problem here is someone is DOING something wrong, and it isn't the
framework guys.

Post by Fernando Tubio
As a user, I want the application to run, not find someone to blame.

But you ARE blaming someone. You're blaming Microsoft for changing the
framework. Problem is, you're ignoring the two other people at fault:

1) The application author, for coding it wrong.
2) Yourself, for upgrading your OS to an unsupported OS _for that application_.

Post by Fernando Tubio
What I expect is that .NET applications should provide a certain degree of
insulation from the underlying platform,

As someone who has been programming Windows applications since Windows
2.0, and PC applications since 1981 I can GUARANTEE that the .Net
application provide a _HUGE_ degree of insulation from the platform.

Post by Fernando Tubio
and when a bad application comes along, the user should
be able to install the version of the framework that was used
to compile the application and run it.

I think you should just run a VM if thats what you want. That's what
XP mode in Win 7 is for...

Post by Fernando Tubio
That is all.

That is _too much_. I regularly joke "Intel and Microsoft, putting
the backwards in backwards-compatible". I'm glad they're finally
stripping away some of the legacy stuff. It hurts performance,
testability and managability far too much already.

[Fernando Tubio]

If you read my original message, it was about finding a way to force an
application to load an assembly from a specific path. I only made a passing
remark where I mentioned that I thought that this was a breaking change. And
I believe that the strongest thing I said in that and subsequent messages
was that I was disappointed that side by side execution was not used to
prevent this kind of problem.

The way you present the facts suggests my only purpose was to complain and
throw the blame exclusively on Microsoft. Far from it. I'm very happy with
Windows 7 and I've been using .NET since its inception. I think that they
have done a very good job overall. You don't have to convince of that.

I can still hope that some things can be improved. You claim that this is
not something that can be solved (by Microsoft). Well, if I were to install
the current release of the framework, then the problem would apparently be
solved. Is this a good idea? I don't know. There could be many reasons why
Microsoft chose not to follow this path. However, I don't think it is
unreasonable for me to have the expectation that side by side deployment
could provide a solution given that this was one of the problems that .NET
was supposed to address.

You also claim that I neglect to put the blame on the application author.
That is not true. I believe that I made it clear, even in my first message,
that they had dropped the ball with this one. However, I'm also very
satisfied with VMware and its products, so I'm not going to walk away from
them either.

Finally, you mention that this is my fault too, for upgrading to an
unsupported OS. Perhaps. The OS may be unsupported, but considering that it
provides .NET 3.5 SP1, which you admit should "provide a _HUGE_ degree of
insulation from the platform", then I think I'm allowed to expect it to
work, and when it doesn't, to express my disappointment.

Everyone, can we drop this now? Seriously.

- Fernando

----- Original Message -----
From: "Marc Brooks" <***@GMAIL.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 8:41 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path

Post by Marc Brooks

Post by Fernando Tubio
Did the application work in Vista? Yes.
Does the application work in Windows 7? No.
Can you do anything to fix it? No, other than DEVPATH hacks.
Is it the fault of the application? Of course.

And it is NOT a solvable problem _for Microsoft_. The only way we get
rid of bad programs is to get rid of bad programmers. Vote with your
feet and get away from that product.

Post by Fernando Tubio
And I think this last point is what gets everyone upset. But from the
perspective of an end user, does it matter?

It should. You don't sue General Motors when your car dies because
someone at the local gas station put diesel in the gas tank. The
problem here is someone is DOING something wrong, and it isn't the
framework guys.

Post by Fernando Tubio
As a user, I want the application to run, not find someone to blame.

But you ARE blaming someone. You're blaming Microsoft for changing the
1) The application author, for coding it wrong.
2) Yourself, for upgrading your OS to an unsupported OS _for that application_.

Post by Fernando Tubio
What I expect is that .NET applications should provide a certain degree of
insulation from the underlying platform,

As someone who has been programming Windows applications since Windows
2.0, and PC applications since 1981 I can GUARANTEE that the .Net
application provide a _HUGE_ degree of insulation from the platform.

Post by Fernando Tubio
and when a bad application comes along, the user should
be able to install the version of the framework that was used
to compile the application and run it.

I think you should just run a VM if thats what you want. That's what
XP mode in Win 7 is for...

Post by Fernando Tubio
That is all.

That is _too much_. I regularly joke "Intel and Microsoft, putting
the backwards in backwards-compatible". I'm glad they're finally
stripping away some of the legacy stuff. It hurts performance,
testability and managability far too much already.
--
Marc C. Brooks
http://musingmarc.blogspot.com
NOT sent from an iPhone
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Marc Brooks]

Post by Fernando Tubio
Finally, you mention that this is my fault too, for upgrading to an
unsupported OS. Perhaps. The OS may be unsupported, but considering that it
provides .NET 3.5 SP1, which you admit should "provide a  _HUGE_ degree of
insulation from the platform", then I think I'm allowed to expect it to
work, and when it doesn't, to express my disappointment.

My point is that the _broken_ application which would fall into this
trap is obviously not specified to run on Windows 7 (or this bug would
have already been fixed by them). Thus you installing Windows 7 and
expecting it to just work is the error... even if it's a laudable
goal, it's your expectation that is in error.

Post by Fernando Tubio
Everyone, can we drop this now? Seriously.

I'm done.

[John Warner]

I have a bit of a problem. I need to automate some things in Word 11/2003. The problem I'm having is I keep getting an Interop error from the Word COM linkage that the Word COM library is not installed. Surfing the net most of the afternoon yesterday and trying some suggestions that did not work I found one that makes a little sense to me. VS 2008 by default seems to install the Interop(s) for Office 2007/12. The comment was there is some sort of bug that breaks linking to Word 11 (and only Word in my case as I can run Excel 2003 from VS 2008 code with no issues) due to the Interop for Office 12 being present. As I read the post, get rid of the version 12 Word Interop (since Word 2007 isn't installed on my dev machine anyway) and my Word 11 automation problems will go away.

I've tried re-registering Word (Winword.exe /r) and that did not help. I tested with VB6 and get a similar error from COM. So as a last gasp, can anyone here tell me what I need to do to un-install the Office 12 Interop(s)? Note OS = Vista Business

I'm also open to any other ideas

Sorry for this being slightly off topic but I figured this might be the best place for the information I need.

Thank you.

John Warner

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Robert Taylor]

I've been working on an Office add-in and found that when you install an Office product it will install the PIA for that product in the GAC. If you add-in was for, say Word and Excel but the user only had Word installed then it's likely that it will throw a COM exception as the Excel PIA will not be installed.

If you install the PIAs from the MSFT PIA msi package then it only installs the PIAs for apps you have installed.

When you install VSTO it installs all the PIAs (in the GAC) so your dev machine will always work even if you only have one Office app installed.

If you build a setup project for your add-in then all the PIAs it references are added to the setup, but as I understand it, you can't 'redistribute' these PIAs so have to exclude them from your setup. So, to stop the add-in throwing a COM Exception you then have to place a try...catch round any statement that references a PIA class; like "if (application is Word.Application)" to stop it crashing your add-in.

Robert Taylor
-----Original Message-----
From: Discussion of advanced .NET topics. [mailto:ADVANCED-***@PEACH.EASE.LSOFT.COM] On Behalf Of John Warner
Sent: 29 May 2009 13:29
To: ADVANCED-***@PEACH.EASE.LSOFT.COM
Subject: [ADVANCED-DOTNET] Interop uninstall ?? Runtime Error -2147310770(8002801d): Automation Error. Library not Installed; Word 2003

I have a bit of a problem. I need to automate some things in Word 11/2003. The problem I'm having is I keep getting an Interop error from the Word COM linkage that the Word COM library is not installed. Surfing the net most of the afternoon yesterday and trying some suggestions that did not work I found one that makes a little sense to me. VS 2008 by default seems to install the Interop(s) for Office 2007/12. The comment was there is some sort of bug that breaks linking to Word 11 (and only Word in my case as I can run Excel 2003 from VS 2008 code with no issues) due to the Interop for Office 12 being present. As I read the post, get rid of the version 12 Word Interop (since Word 2007 isn't installed on my dev machine anyway) and my Word 11 automation problems will go away.

I've tried re-registering Word (Winword.exe /r) and that did not help. I tested with VB6 and get a similar error from COM. So as a last gasp, can anyone here tell me what I need to do to un-install the Office 12 Interop(s)? Note OS = Vista Business

I'm also open to any other ideas

Sorry for this being slightly off topic but I figured this might be the best place for the information I need.

Thank you.

John Warner

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[John Warner]

It seems after I frankly found the PIA for Office 2007 right in Programs and Features or whatever it's called in Vista that I could uninstall it. Others might want to make a mental note that if you are trying to automate Word 2003 and the PIA for Office 2007 is present you will have issues. The cure is removing the PIA. That is the only thing I did and now I get no errors running the same code that the day before would not run. This seems like a serious issue for MS to look into but they have no method for reporting bugs that does not involve me betting some serious money that it is a bug and so they won't charge me for a tech support contact. So alas it will go unreported because MS does not actually care that this issue exists.

Regardless of my rant about MS not caring about defects, this only appears to affect Word and not Excel. You can reproduce this by simply taking a machine with Office 2003 installed, write a bit of code to invoke a couple of properties in Word and run it. Then install the Office 2007 PIAs and the same code will now be broken.

Thanks to all who offered help.

John Warner

-----Original Message-----
From: Discussion of advanced .NET topics. [mailto:ADVANCED-
Sent: Saturday, May 30, 2009 5:09 AM
Subject: Re: [ADVANCED-DOTNET] Interop uninstall ?? Runtime Error -
2147310770(8002801d): Automation Error. Library not Installed; Word 2003
I've been working on an Office add-in and found that when you install an Office
product it will install the PIA for that product in the GAC. If you add-in was for,
say Word and Excel but the user only had Word installed then it's likely that it
will throw a COM exception as the Excel PIA will not be installed.
If you install the PIAs from the MSFT PIA msi package then it only installs the
PIAs for apps you have installed.
When you install VSTO it installs all the PIAs (in the GAC) so your dev
machine will always work even if you only have one Office app installed.
If you build a setup project for your add-in then all the PIAs it references are
added to the setup, but as I understand it, you can't 'redistribute' these PIAs so
have to exclude them from your setup. So, to stop the add-in throwing a COM
Exception you then have to place a try...catch round any statement that
references a PIA class; like "if (application is Word.Application)" to stop it
crashing your add-in.
Robert Taylor
-----Original Message-----
From: Discussion of advanced .NET topics. [mailto:ADVANCED-
Sent: 29 May 2009 13:29
Subject: [ADVANCED-DOTNET] Interop uninstall ?? Runtime Error -
2147310770(8002801d): Automation Error. Library not Installed; Word 2003
I have a bit of a problem. I need to automate some things in Word 11/2003.
The problem I'm having is I keep getting an Interop error from the Word COM
linkage that the Word COM library is not installed. Surfing the net most of the
afternoon yesterday and trying some suggestions that did not work I found one
that makes a little sense to me. VS 2008 by default seems to install the
Interop(s) for Office 2007/12. The comment was there is some sort of bug that
breaks linking to Word 11 (and only Word in my case as I can run Excel 2003
from VS 2008 code with no issues) due to the Interop for Office 12 being
present. As I read the post, get rid of the version 12 Word Interop (since Word
2007 isn't installed on my dev machine anyway) and my Word 11 automation
problems will go away.
I've tried re-registering Word (Winword.exe /r) and that did not help. I tested
with VB6 and get a similar error from COM. So as a last gasp, can anyone
here tell me what I need to do to un-install the Office 12 Interop(s)? Note OS =
Vista Business
I'm also open to any other ideas
Sorry for this being slightly off topic but I figured this might be the best place for
the information I need.
Thank you.
John Warner
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives
===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Peter Ritchie]

By "anyone", I'm including Framework designers. So, no, I'm not agreeing with you other than to agree that it's a pain for the end-user. But, it's a pain caused by the 3rd party and only that 3rd party can solve it.

The fact that you think the issue should be addressed in the Framework or through deployment of the Framework means you've started an API discussion, I'm not trying to push you into an API discussion. Call it a deployment issue if you want; but it's a deployment issue of the Framework and that's just calling it something else instead of admitting the issue can only be solved by the 3rd party by writing better code in general and fixing this particular issue.

-- Peter

Post by Fernando Tubio
Finally! You seem to agree with me
... "There's really nothing anyone can do to avoid breaking an application
that is making incorrect assumptions while reflecting code."...
So it is a breaking change, sorry, a "disruptive alteration".
I insist that you are trying to push me into an API discussion when I
believe this is a deployment issue, and a very difficult one. I think they
can fix all the APIs that they want, and I'm glad that this happens. I'm not
convinced that claiming that this is still .NET 3.5 SP1 is the way to go.
And if Windows 7 introduces changes that can potentially disrupt
applications, then you should still be able to deploy the original
framework bits side by side and get on with your life. But I'm sure that
there are a lot more issues to consider other than maintaining compatibility
with a badly written application. Perhaps this is the reason why I'm
reluctant to "pick a side". That, and the fact that if you look at the
subject line, you will recall what my primary concern was. Certainly not
argueing for the inmutability of the framework APIs or the bad use of
reflection.

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

[Fernando Tubio]

..."the issue can only be solved by the 3rd party by writing better code in
general and fixing this particular issue."

The issue should be solved by the 3rd party. Meanwhile, the end-user should
be able to install the version of the framework that was used to compile the
application and move along.

- Fernando

----- Original Message -----
From: "Peter Ritchie" <***@PETERRITCHIE.COM>
To: <ADVANCED-***@PEACH.EASE.LSOFT.COM>
Sent: Tuesday, May 26, 2009 6:13 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path


By "anyone", I'm including Framework designers. So, no, I'm not agreeing
with you other than to agree that it's a pain for the end-user. But, it's a
pain caused by the 3rd party and only that 3rd party can solve it.

The fact that you think the issue should be addressed in the Framework or
through deployment of the Framework means you've started an API discussion,
I'm not trying to push you into an API discussion. Call it a deployment
issue if you want; but it's a deployment issue of the Framework and that's
just calling it something else instead of admitting the issue can only be
solved by the 3rd party by writing better code in general and fixing this
particular issue.

-- Peter

Post by Fernando Tubio
Finally! You seem to agree with me
... "There's really nothing anyone can do to avoid breaking an application
that is making incorrect assumptions while reflecting code."...
So it is a breaking change, sorry, a "disruptive alteration".
I insist that you are trying to push me into an API discussion when I
believe this is a deployment issue, and a very difficult one. I think they
can fix all the APIs that they want, and I'm glad that this happens. I'm not
convinced that claiming that this is still .NET 3.5 SP1 is the way to go.
And if Windows 7 introduces changes that can potentially disrupt
applications, then you should still be able to deploy the original
framework bits side by side and get on with your life. But I'm sure that
there are a lot more issues to consider other than maintaining
compatibility
with a badly written application. Perhaps this is the reason why I'm
reluctant to "pick a side". That, and the fact that if you look at the
subject line, you will recall what my primary concern was. Certainly not
argueing for the inmutability of the framework APIs or the bad use of
reflection.

===================================
View archives and manage your subscription(s) at
http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives