🚀 go-pugleaf

Hi Chad,

> Have a .NET app that I've shipped. Works on all computers, except on user.
> He gets this error when Indy is accessed. BUT he has only one copy of Indy,
> Delphi.VclRtl, and Borland.Delphi - and they are the SAME versions I have...
> Any ideas?

So the only difference is that he doesn't have Delphi installed, and you
have?

Check assembly policy settings - chances are that a reference to an
assembly version is not exactly right (not exactly the version of the
actual assembly file), but an assembly policy on your machine (where
Delphi is installed) is solving that.

I have a similar problem (and solved it) with the BDP. The actual
assemblies are 2.2.0.0 yet Delphi still creates applications using and
referring to 2.0.0.0 (which is OK on my local machine, since assembly
policy files make sure the right files are used with the 2.0.0.0 version
- but once you deploy, you need to fix that)...

> Ive since built a fresh XP VM - and same result. The ASMs I ship are Indy,
> RtlVcl, Vcl, and Delphi. I only have one copy of each on my system, and it
> works locally.

Try to run the application on a fresh XP VM *without* Delphi 2005
installed. See if that can help you reproduce the problem (chances are
it does, and then you're one step further ;-)
 
> System.IO.FileLoadException
> The located assembly's manifest definition with name 'Borland.VclRtl' does
> not match the assembly reference.

So the actual assembly file has a different version number than the
version number which is referred to in your application (or probably in
Indy).

I think that Indy was built with a different (minor) version of
Borland.VclRtl and now still wants to find that slightly older version.
Since it can't find it, it won't load. Either you need to "patch" Indy,
or you need to install an assembly policy that will tell Indy to load
the newer version instead of the older one. Do I make any sense?

> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
>       "Programming is an art form that fights back"

Groetjes,
          Bob Swart (aka Dr.Bob - www.DrBob42.com)

PS: This is called "No more DLL Hell" ;-)

-- 
Bob Swart Training & Consultancy (eBob42) - Borland Technology Partner
Delphi 2005 PDF manuals available from http://www.drbob42.com/training

Bob Swart <b.swart@chello.nl> wrote in news:427DB127.F5EB4585@chello.nl:
> So the only difference is that he doesn't have Delphi installed, and you
> have?

Not sure. He definitely does not have D2005, but I think that other users 
that it works on may not have D2005 as well. But I cannot confirm for the 
others users, many of them do have D2005.

> Check assembly policy settings - chances are that a reference to an
> assembly version is not exactly right (not exactly the version of the
> actual assembly file), but an assembly policy on your machine (where
> Delphi is installed) is solving that.

Where do I look for that?

>> Ive since built a fresh XP VM - and same result. The ASMs I ship are
>> Indy, RtlVcl, Vcl, and Delphi. I only have one copy of each on my
>> system, and it works locally.
> 
> Try to run the application on a fresh XP VM *without* Delphi 2005

It is. :) The VM has never had D2005. Its a fresh XP. Had Delphi 7 once, 
and has Visual Studio, but not Delphi.NET.

> So the actual assembly file has a different version number than the
> version number which is referred to in your application (or probably in
> Indy).

Yes, thats what it appears to be.

> I think that Indy was built with a different (minor) version of
> Borland.VclRtl and now still wants to find that slightly older version.
> Since it can't find it, it won't load. Either you need to "patch" Indy,

Would SP2 change the VclRtl? Does it delete and remove the old on and 
update it? If so, IMO this is a bit dangerous if it breaks applications.

> or you need to install an assembly policy that will tell Indy to load
> the newer version instead of the older one. Do I make any sense?

Ok, how do I install an assembly policy? This is the stuff in the .config 
file right?

> PS: This is called "No more DLL Hell" ;-)

Yeah.... Well at least to doesnt just AV anymore.
 



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

Bob Swart <b.swart@chello.nl> wrote in news:427DB127.F5EB4585@chello.nl:
> Check assembly policy settings - chances are that a reference to an
> assembly version is not exactly right (not exactly the version of the

Arg! Here is what it is. I have an application in C# that uses Indy. So it 
references Indy. But VS complains that Indy needs VCLRTL, so I add that. BUT 
Indy is built with an old version of RTLVCL. So when you look in the EXE with 
the .NET tools it shows it needs TWO versions of VCLRTL and TWO of 
Delphi.dll.

Altering the config file wont help - that only affects the EXE. Already tried 
that. And unfortuantely for this app I cant rebuild Indy right now.

So - it works localy because for ASM's you can install a policy in the GAC - 
which Borland does. But our apps dont.. So now I have to mess with the GAC on 
the users machine, or try and build against the old ASM.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

At 08:26:47, 08.05.2005, Bob Swart wrote:

> Hi Chad,
> 
> > Have a .NET app that I've shipped. Works on all computers, except on
> > user.  He gets this error when Indy is accessed. BUT he has only one
> > copy of Indy, Delphi.VclRtl, and Borland.Delphi - and they are the
> > SAME versions I have...  Any ideas?
> 
> So the only difference is that he doesn't have Delphi installed, and you
> have?
> 
> Check assembly policy settings - chances are that a reference to an
> assembly version is not exactly right (not exactly the version of the
> actual assembly file), but an assembly policy on your machine (where
> Delphi is installed) is solving that.

Correct. 

Example:

There is an assembly policy on my machine (policy.9.0.1882.something)
which maps to Borland.Delphi.dll 9.0.1882.xxxxx, when 9.0.1761.yyyyy is
specified in your app. 9.0.1761 is the version of plain D2005, 9.0.1882
is the version after patch 2.


-- 
Rudy Velthuis [TeamB]
 
"The only rules comedy can tolerate are those of taste, and the only
 limitations those of libel." -- James Thurber (1894-1961)

"Chad Z. Hower aka Kudzu" <cpub@hower.org> wrote in
news:Xns96509E5AE19EEcpub@127.0.0.1: 
> Arg! Here is what it is. I have an application in C# that uses Indy. So

FWIW I "solved" it for now by getting the old assemblies and putting them in 
my app dir and compiling C# against those references instead of the GAC ones.

The "real" solution would be to register the newer ones in the GAC with an 
assembly config, but I dont have an install for this app and GACUTIL isnt 
distroed with the FCL, only SDK, so I chose the shortest solution for now.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

Rudy,

unfortunatly one does not get the Policy Dll files with SP2 so the
Policies could also be deployed to a user's machine. It would be wise
for SP2 to also copy the Policy DLL files to the Common Files\BDE\...
directory for deployment usage.

Peter

Rudy Velthuis [TeamB] wrote:

> At 08:26:47, 08.05.2005, Bob Swart wrote:
> 
> > Hi Chad,
> > 
> > > Have a .NET app that I've shipped. Works on all computers, except
> > > on user.  He gets this error when Indy is accessed. BUT he has
> > > only one copy of Indy, Delphi.VclRtl, and Borland.Delphi - and
> > > they are the SAME versions I have...  Any ideas?
> > 
> > So the only difference is that he doesn't have Delphi installed,
> > and you have?
> > 
> > Check assembly policy settings - chances are that a reference to an
> > assembly version is not exactly right (not exactly the version of
> > the actual assembly file), but an assembly policy on your machine
> > (where Delphi is installed) is solving that.
> 
> Correct. 
> 
> Example:
> 
> There is an assembly policy on my machine (policy.9.0.1882.something)
> which maps to Borland.Delphi.dll 9.0.1882.xxxxx, when 9.0.1761.yyyyy
> is specified in your app. 9.0.1761 is the version of plain D2005,
> 9.0.1882 is the version after patch 2.

At 09:04:33, 09.05.2005, Peter Sawatzki wrote:

> Rudy,
> 
> unfortunatly one does not get the Policy Dll files

There are no policy DLL files. Policies are simply GAC entries which
divert the loading of a DLL of one version to another version. The DLLs
files are the ones that come with Delphi and the patches.

Have a look in <Windows directory>\assembly\GAC, both with the Windows
Explorer and then with a program like File Commander or Total Commander.
-- 
Rudy Velthuis [TeamB]

"83.7% of all statistics are made up" - Stephen Wright

"Rudy Velthuis [TeamB]" <velthuis@gmail.com> wrote in news:xn0e20gtn23pui00k-
moderator@newsgroups.borland.com:
> There is an assembly policy on my machine (policy.9.0.1882.something)
> which maps to Borland.Delphi.dll 9.0.1882.xxxxx, when 9.0.1761.yyyyy is
> specified in your app. 9.0.1761 is the version of plain D2005, 9.0.1882
> is the version after patch 2.

According to MSDN the policy file means nothing - you have to install it into 
the GAC using that file, and then this information is stored in the GAC. So 
without building an install with GAC support...


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

"Peter Sawatzki" <peter@sawatzki.de> wrote in news:427f0b81$1
@newsgroups.borland.com:
> unfortunatly one does not get the Policy Dll files with SP2 so the
> Policies could also be deployed to a user's machine. It would be wise
> for SP2 to also copy the Policy DLL files to the Common Files\BDE\...
> directory for deployment usage.

But AFAIK you would still have to install to the GAC and specify the policy 
file.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

At 12:44:23, 09.05.2005, Chad Z. Hower aka Kudzu wrote:

> "Rudy Velthuis [TeamB]" <velthuis@gmail.com> wrote in
> news:xn0e20gtn23pui00k- moderator@newsgroups.borland.com:
> > There is an assembly policy on my machine (policy.9.0.1882.something)
> > which maps to Borland.Delphi.dll 9.0.1882.xxxxx, when 9.0.1761.yyyyy
> > is specified in your app. 9.0.1761 is the version of plain D2005,
> > 9.0.1882 is the version after patch 2.
> 
> According to MSDN the policy file means nothing - you have to install
> it into the GAC using that file, and then this information is stored in
> the GAC. So without building an install with GAC support...

There is no "policy file". Each policy is a directory in the GAC. 

I guess that if you need a specific version, you don't install it into
the GAC, but put it in the same directory as the (main) executable.
-- 
Rudy Velthuis [TeamB]

"Richard Nixon is a no good, lying bastard. He can lie out of both
 sides of his mouth at the same time, and if he ever caught himself
 telling the truth, he'd lie just to keep his hand in."
 -- Harry S. Truman.

Rudy,

of course there are policy DLL files! The policy DLL files get
installed in the GAC and redirect assembly versions - this is how the
redirection rules get into the GAC: you hace to write a Policy DLL. For
example this is the source file "PS.Data.iSeries.config" to my
policy.2.0.PS.Data.iSeries.dll that redirects calls to version 2.0.0.0
to 2.2.0.0.

<?xml version="1.0" ?>
<configuration xmlns:asm="urn:schemas-microsoft-com:asm.v1">
  <runtime>
    <asm:assemblyBinding>
<!-- one dependentAssembly per unique assembly name -->
      <asm:dependentAssembly>
        <asm:assemblyIdentity
           name="PS.Data.iSeries"
           publicKeyToken="df047b757d3f379a" />
<!-- one bindingRedirect per redirection -->
        <asm:bindingRedirect oldVersion="2.0.0.0" newVersion="2.2.0.0"
/>
      </asm:dependentAssembly>
    </asm:assemblyBinding>
  </runtime>
</configuration>   

this has to be compiled with al.exe into a DLL and then installed in
the GAC. You compile this with something like the following command:

al.exe /link:PS.Data.iSeries.config /out:policy.2.0.PS.Data.iSeries.dll
/keyf:ps.key /v:2.0.0.0

then you install the policy DLL with "GACUTIL /i
policy.2.0.PS.Data.iSeries.dll"

Something similar is done inside the Delphi 2005 SP2 update (there are
many policy DLLs).

Peter

Rudy Velthuis [TeamB] wrote:

> At 09:04:33, 09.05.2005, Peter Sawatzki wrote:
> 
> > Rudy,
> > 
> > unfortunatly one does not get the Policy Dll files
> 
> There are no policy DLL files. Policies are simply GAC entries which
> divert the loading of a DLL of one version to another version. The
> DLLs files are the ones that come with Delphi and the patches.
> 
> Have a look in <Windows directory>\assembly\GAC, both with the Windows
> Explorer and then with a program like File Commander or Total
> Commander.

Chad,

yes, it has to be installed, but this is the way these "satellite"
assemblies are resolved.

Peter

Chad Z. Hower aka Kudzu wrote:

> "Peter Sawatzki" <peter@sawatzki.de> wrote in news:427f0b81$1
> @newsgroups.borland.com:
> > unfortunatly one does not get the Policy Dll files with SP2 so the
> > Policies could also be deployed to a user's machine. It would be
> > wise for SP2 to also copy the Policy DLL files to the Common
> > Files\BDE\...  directory for deployment usage.
> 
> But AFAIK you would still have to install to the GAC and specify the
> policy file.
> 
> 
> --
> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
>       "Programming is an art form that fights back"
> 
> Blog: http://blogs.atozed.com/kudzu

Chad,

another option would be to make a yourapp.exe.config file for binding
redirection.

Peter

Chad Z. Hower aka Kudzu wrote:

> "Rudy Velthuis [TeamB]" <velthuis@gmail.com> wrote in
> news:xn0e20gtn23pui00k- moderator@newsgroups.borland.com:
> > There is an assembly policy on my machine
> > (policy.9.0.1882.something) which maps to Borland.Delphi.dll
> > 9.0.1882.xxxxx, when 9.0.1761.yyyyy is specified in your app.
> > 9.0.1761 is the version of plain D2005, 9.0.1882 is the version
> > after patch 2.
> 
> According to MSDN the policy file means nothing - you have to install
> it into the GAC using that file, and then this information is stored
> in the GAC. So without building an install with GAC support...
> 
> 
> --
> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
>       "Programming is an art form that fights back"
> 
> Blog: http://blogs.atozed.com/kudzu

At 13:40:36, 09.05.2005, Peter Sawatzki wrote:

> Rudy,
> 
> of course there are policy DLL files! The policy DLL files get
> installed in the GAC and redirect assembly versions

I thought you meant they were DLLs. They aren't.
-- 
Rudy Velthuis [TeamB]

"Too many pieces of music finish too long after the end."
    - Igor Stravinsky (1882-1971)

Rudy,

in the same sense you could say that BDP drivers are not DLLs - they
are in the GAC too and after installing them in the GAC you no longer
need them!

Policies are DLLs and are in the GAC. You can see by yourself:

 Verzeichnis von
C:\WINDOWS\assembly\GAC\policy.2.0.Borland.Data.Common\9.0.1882
.30496__91d62ebb5b0d1b1b

11.03.2005  14:22    <DIR>          .
11.03.2005  14:22    <DIR>          ..
11.03.2005  14:17               567
policy.2.0.Borland.Data.Common.config
11.03.2005  14:17             3.072 policy.2.0.Borland.Data.Common.dll
11.03.2005  14:22               225 __AssemblyInfo__.ini
               3 Datei(en)          3.864 Bytes
               2 Verzeichnis(se), 204.550.705.152 Bytes frei

[C:\WINDOWS\assembly\GAC\policy.2.0.Borland.Data.Common\9.0.1882.30496__
91d62ebb
5b0d1b1b]

I'm confident if you take these DLLs and copy them in the same
directory as you app that the policies will be applied.


Peter

Rudy Velthuis [TeamB] wrote:

> At 13:40:36, 09.05.2005, Peter Sawatzki wrote:
> 
> > Rudy,
> > 
> > of course there are policy DLL files! The policy DLL files get
> > installed in the GAC and redirect assembly versions
> 
> I thought you meant they were DLLs. They aren't.

Chad,

maybe an option would be to copy the policy DLLs files from your
machine's GAC into the user's machines app directory. You can walk into
the directory \windows\assembly\gac with cmd.exe or use explorer to see
what's in the gac after applying the following registry setting:

"The Global Assembly Cache (GAC), when viewed using Explorer, has its
view rendered in a special manner by the OS shell - you see all the
assemblies, their strong name details, processor architecture and other
details. To view the physical file system structure of the GAC, create
a DWORD entry by the name DisableCacheViewer under the registry key,
HKEY_LOCAL_MACHINE\Software\Microsoft\Fusion, and set its value to 1.
Navigate to your GAC folder now and see the new view. "

Peter

Peter Sawatzki wrote:

> Chad,
> 
> yes, it has to be installed, but this is the way these "satellite"
> assemblies are resolved.
> 
> Peter
> 

> Chad Z. Hower aka Kudzu wrote:
> 
> > "Peter Sawatzki" <peter@sawatzki.de> wrote in news:427f0b81$1
> > @newsgroups.borland.com:
> > > unfortunatly one does not get the Policy Dll files with SP2 so the
> > > Policies could also be deployed to a user's machine. It would be
> > > wise for SP2 to also copy the Policy DLL files to the Common
> > > Files\BDE\...  directory for deployment usage.
> > 
> > But AFAIK you would still have to install to the GAC and specify the
> > policy file.
> > 
> > 
> > --
> > Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
> >       "Programming is an art form that fights back"
> > 
> > Blog: http://blogs.atozed.com/kudzu

At 14:15:02, 09.05.2005, Peter Sawatzki wrote:

> Rudy,
> 
> in the same sense you could say that BDP drivers are not DLLs - they
> are in the GAC too and after installing them in the GAC you no longer
> need them!
> 
> Policies are DLLs and are in the GAC. You can see by yourself:
> 
>  Verzeichnis von
> C:\WINDOWS\assembly\GAC\policy.2.0.Borland.Data.Common\9.0.1882
> .30496__91d62ebb5b0d1b1b
> 
> 11.03.2005  14:22    <DIR>          .
> 11.03.2005  14:22    <DIR>          ..
> 11.03.2005  14:17               567
> policy.2.0.Borland.Data.Common.config
> 11.03.2005  14:17             3.072 policy.2.0.Borland.Data.Common.dll
> 11.03.2005  14:22               225 AssemblyInfo.ini
>                3 Datei(en)          3.864 Bytes
>                2 Verzeichnis(se), 204.550.705.152 Bytes frei
> 
> [C:\WINDOWS\assembly\GAC\policy.2.0.Borland.Data.Common\9.0.1882.30496__
> 91d62ebb
> 5b0d1b1b]
> 
> I'm confident if you take these DLLs and copy them in the same
> directory as you app that the policies will be applied.
> 
> 
> Peter
> 
> Rudy Velthuis [TeamB] wrote:
> 
> > At 13:40:36, 09.05.2005, Peter Sawatzki wrote:
> > 
> > > Rudy,
> > > 
> > > of course there are policy DLL files! The policy DLL files get
> > > installed in the GAC and redirect assembly versions
> > 
> > I thought you meant they were DLLs. They aren't.

Hmmm... I see they can be. But they are only header with version. 3072
bytes in size.

-- 
Rudy Velthuis [TeamB]

"The difference between fiction and reality? Fiction has to make sense."
    - Tom Clancy

"Rudy Velthuis [TeamB]" <velthuis@gmail.com> wrote in news:xn0e21oak2yk4t00k-
moderator@newsgroups.borland.com:
>> According to MSDN the policy file means nothing - you have to install
>> it into the GAC using that file, and then this information is stored in
>> the GAC. So without building an install with GAC support...
> 
> There is no "policy file". Each policy is a directory in the GAC. 
> 
> I guess that if you need a specific version, you don't install it into
> the GAC, but put it in the same directory as the (main) executable.

Thats what I said. But thiere IS a policy file - that you can create and then 
pass to GACUtil when installing the asm.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

"Peter Sawatzki" <peter@sawatzki.de> wrote in news:427f4d22$1
@newsgroups.borland.com:
> another option would be to make a yourapp.exe.config file for binding
> redirection.

No, that wont work. That only affects the EXE, not asms loaded by asms that 
the exe loads.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

"Peter Sawatzki" <peter@sawatzki.de> wrote in news:427f56f1$1
@newsgroups.borland.com:
> maybe an option would be to copy the policy DLLs files from your
> machine's GAC into the user's machines app directory. You can walk into
> the directory \windows\assembly\gac with cmd.exe or use explorer to see
> what's in the gac after applying the following registry setting:

Its not good to mess with the GAC directly, and ASMs dont have policy files 
per se.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

At 22:41:24, 09.05.2005, Chad Z. Hower aka Kudzu wrote:

> > I guess that if you need a specific version, you don't install it into
> > the GAC, but put it in the same directory as the (main) executable.
> 
> Thats what I said. But thiere IS a policy file - that you can create
> and then pass to GACUtil when installing the asm.

True.
-- 
Rudy Velthuis [TeamB]

"Never interrupt your enemy when he is making a mistake."
    - Napoleon Bonaparte (1769-1821)

Rudy,

this is not only the header, it is the complete policy DLL. For example
the Policy DLL for my driver (I told you in a previous message how to
make a policy DLL) is 3kb in size too. See below for steps how to make
your own policy DLL:

1. Create XML text file and call it mypol.config:
<?xml version="1.0" ?>
<configuration xmlns:asm="urn:schemas-microsoft-com:asm.v1">
  <runtime>
    <asm:assemblyBinding>
<!-- one dependentAssembly per unique assembly name -->
      <asm:dependentAssembly>
        <asm:assemblyIdentity
           name="PS.Data.iSeries"
           publicKeyToken="df047b757d3f379a" />
<!-- one bindingRedirect per redirection -->
        <asm:bindingRedirect oldVersion="2.0.0.0" newVersion="2.2.0.0"
/>
      </asm:dependentAssembly>
    </asm:assemblyBinding>
  </runtime>
</configuration>     

2. run al.exe like this:
al.exe /link:mypol.config /out:policy.2.0.mydriver.dll
/keyf:yourkey.snk /v:2.0.0.0

You receive a policy DLL "policy.2.0.mydriver.dll" that you can also
install in the GAC with GACUtil.

Peter

Rudy Velthuis [TeamB] wrote:
> > Rudy Velthuis [TeamB] wrote:
> > 
> > > At 13:40:36, 09.05.2005, Peter Sawatzki wrote:
> > > 
> > > > Rudy,
> > > > 
> > > > of course there are policy DLL files! The policy DLL files get
> > > > installed in the GAC and redirect assembly versions
> > > 
> > > I thought you meant they were DLLs. They aren't.
> 
> Hmmm... I see they can be. But they are only header with version. 3072
> bytes in size.

At 12:39:02, 10.05.2005, Peter Sawatzki wrote:

> Rudy,
> 
> this is not only the header, it is the complete policy DLL.

I know. I meant it only consists of a PE header and a resource.


-- 
Rudy Velthuis [TeamB]

"Love is the answer - but while you're waiting for the answer sex
 raises some pretty good questions." -- Woody Allen

Chad Z. Hower aka Kudzu wrote:

> "Peter Sawatzki" <peter@sawatzki.de> wrote in news:427f56f1$1
> @newsgroups.borland.com:
> > maybe an option would be to copy the policy DLLs files from your
> > machine's GAC into the user's machines app directory. You can walk
> > into the directory \windows\assembly\gac with cmd.exe or use
> > explorer to see what's in the gac after applying the following
> > registry setting:
> 
> Its not good to mess with the GAC directly, and ASMs dont have policy
> files per se.

Chad,

If you compile (like you did) against newer ASMs and deploy older ASMs
you have a problem. I think you said for some reason you couldn't
recompile/deploy against the older ASM so I was trying to communicate
to you how you could take the policy DLLs from your D2005 SP2 system
and apply them to a user's system without installing D2005 SP2 on it.

But I still think you should make a yourapp.exe.config file and
redirectbind there:

<configuration>
  <startup>
    <supportedRuntime version="v1.1.4322"/>
  </startup>
  <runtime>
    <dependentAssembly>
        <assemblyIdentity name="Chads.Class"
publicKeyToken="####key#token#in#hex###" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535"
newVersion="10.0.0.2"/>
    </dependentAssembly>
  </runtime>
</configuration>

Peter

Chad,

o.k. understood. 

Peter

Chad Z. Hower aka Kudzu wrote:

> "Peter Sawatzki" <peter@sawatzki.de> wrote in news:427f4d22$1
> @newsgroups.borland.com:
> > another option would be to make a yourapp.exe.config file for
> > binding redirection.
> 
> No, that wont work. That only affects the EXE, not asms loaded by
> asms that the exe loads.
> 
> 
> --
> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
>       "Programming is an art form that fights back"
> 
> Blog: http://blogs.atozed.com/kudzu

"Peter Sawatzki" <peter@sawatzki.de> wrote in news:42809738$1
@newsgroups.borland.com:
> recompile/deploy against the older ASM so I was trying to communicate
> to you how you could take the policy DLLs from your D2005 SP2 system

But you cant do that unless you also register to the GAC, which I dont do 
right now for other reasons. And since GACUTIL only comes with the SDK, not 
the framework users cant even do it themselves.

> But I still think you should make a yourapp.exe.config file and
> redirectbind there:

It wont work. This will only affect when the EXE loads ASMs, not when its 
depenedent ASMs load ASMs.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

Hi All

This thread has been interesting. Glad to see that .NET has made things so 
much simpler then good old DLL hell. <g>

Regards, Frederick C. Wilt

"Frederick C. Wilt" <fcwilt@mindspring.com> wrote in news:4280e038
@newsgroups.borland.com:
> This thread has been interesting. Glad to see that .NET has made things so 
> much simpler then good old DLL hell. <g>

Well on first look - it still appears a mess, but it is a lot better than DLL 
hell, once one understands all of it.. It made the big messes smaller, but 
sometimes the really simple stuff got sacrificed - but realy in the name of 
caution.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu