"Sergey M" <no_spam_for_you> wrote in message
news:%23t2CUQSiEHA.1764@TK2MSFTNGP10.phx.gbl...
> Hi all,
>
> I have an application that collects GACed assemblies published by
> Microsoft only and their types using Fusion APIs. The application's
> written using VS.NET 2003. I'd like for the application to only target
> run-time v1.1 GACed assemblies.
>
> I've managed to isolate Microsoft's assemblies by validating
> PublicKeyToken. The problem I'm having is trying to figure out how to
> associate an assembly in GAC with run-time v1.1. I'd like to avoid
> dynamically loading run-time v1.0 assemblies.
>
> Trying to match application run-time version (Environment.Version) to
> assembly version works most of the times but there are some
exceptions.
> Some of the VS.NET 2003 assemblies have a different version scheme
that
> starts with major version 7.0. Some have different builder numbers for
> VS.NET 2002 and 2003. There are also few of them that only have one
> version in GAC and it matches VS.NET 2002 version number, yet is
> installed into v1.1 folder, EnvDTE v7.0.3300.0 for example.
>
> Could anyone shed some light onto this or give me a push into a right
> direction please? Thanks in advance.
> --
> Sergey M
> http://www.usysware.com/dpack/
>
>
>

> The set of assemblies included with v1.1 of the framework is limited.
> Why don't you just keep a static list of assemblies known to be
> included?

"Sergey M" <no_spam_for_you> wrote in message
news:%23t2CUQSiEHA.1764@TK2MSFTNGP10.phx.gbl...
> Hi all,
>
> I have an application that collects GACed assemblies published by
> Microsoft only and their types using Fusion APIs. The application's
> written using VS.NET 2003. I'd like for the application to only target
> run-time v1.1 GACed assemblies.
>
> I've managed to isolate Microsoft's assemblies by validating
> PublicKeyToken. The problem I'm having is trying to figure out how to
> associate an assembly in GAC with run-time v1.1. I'd like to avoid
> dynamically loading run-time v1.0 assemblies.
>
> Trying to match application run-time version (Environment.Version) to
> assembly version works most of the times but there are some exceptions.
> Some of the VS.NET 2003 assemblies have a different version scheme that
> starts with major version 7.0. Some have different builder numbers for
> VS.NET 2002 and 2003. There are also few of them that only have one
> version in GAC and it matches VS.NET 2002 version number, yet is
> installed into v1.1 folder, EnvDTE v7.0.3300.0 for example.
>
> Could anyone shed some light onto this or give me a push into a right
> direction please? Thanks in advance.
> --
> Sergey M
> http://www.usysware.com/dpack/
>
>
>

> Since you are using .Net framework 1.1, the following should work for

> Anything starts with a version number 7.x belongs to Visual Studio.
> For 1.0 and 1.1 framework assemblies, their version numbers always
> start with 1.0. Some of VS assemblies are shared between VS 2002 and
> VS 2003.

"Sergey M" <no@spam.com> wrote in message
news:eylgyYLjEHA.3232@TK2MSFTNGP10.phx.gbl...
> Junfeng,
>
> > Anything starts with a version number 7.x belongs to Visual Studio.
> > For 1.0 and 1.1 framework assemblies, their version numbers always
> > start with 1.0. Some of VS assemblies are shared between VS 2002 and
> > VS 2003.
>
> I do most of what you've described already. What I seem to be having
> problems with is trying to figure out on how to not filter out VS.NET
> 2002/2003 shared assemblies. According to you, shared assemblies would
> show up as belonging to framework v1.0. Yet, they also get referenced
> and loaded by VS.NET 2003, which obviously uses v1.1.
>
> Do you have any suggestions as to how to detect those kinds of
> assemblies as shared, short of creating a custom list of assembly
> names to check against? I keep on bring it up but just one example of
> such assembly is EnvDTE one.
>
> Any further help or suggestions would be very much appreciated.
> Thanks.
> --
> Sergey Mishkovskiy
> http://www.usysware.com/dpack/
>
>
>