ASP.NET application and GAC

[Amelyan]

What is the deal with ASP.NET and signed assemblies? I have experienced
some weird behavior of my web application where it looked like my asp.net
application wasn't even looking into GAC. Then, I saw a brief mention on
the web "ASP.NET doesn't pick up signed assesmblies from GAC".

Does anyone who knows can give more explanation?

Thanks,
Amelyan

[Brad Quinn]

ASP.NET picks up signed assemblies just fine, at least for me it does.

Are you dynamically loading the assembly? If you are, make sure that you're
using the fully qualified type i.e. Version, Culture and PublicKeyToken.

You'll also want to include this information (in the section element in the
configSections node) if the GAC'd assembly has a class that implements
IConfigurationSectionHandler.

"Amelyan" wrote:

What is the deal with ASP.NET and signed assemblies? I have experienced
some weird behavior of my web application where it looked like my asp.net
application wasn't even looking into GAC. Then, I saw a brief mention on
the web "ASP.NET doesn't pick up signed assesmblies from GAC".

Does anyone who knows can give more explanation?

Thanks,
Amelyan

[Amelyan]

I statically link the assembly to my project and it doesn't implement
IConfigurationSectionHandler. Usually, GAC is the first place where .net
application searches for its assemblies. However, this doesn't seem to be
the case with ASP.NET applications.

Do you know why?

Thanks,
Amelyan

"Brad Quinn" <Br*******@discussions.microsoft.com> wrote in message
news:41**********************************@microsof t.com...

ASP.NET picks up signed assemblies just fine, at least for me it does.

Are you dynamically loading the assembly? If you are, make sure that
you're
using the fully qualified type i.e. Version, Culture and PublicKeyToken.

You'll also want to include this information (in the section element in
the
configSections node) if the GAC'd assembly has a class that implements
IConfigurationSectionHandler.

"Amelyan" wrote:

What is the deal with ASP.NET and signed assemblies? I have experienced
some weird behavior of my web application where it looked like my asp.net
application wasn't even looking into GAC. Then, I saw a brief mention on
the web "ASP.NET doesn't pick up signed assesmblies from GAC".

Does anyone who knows can give more explanation?

Thanks,
Amelyan

[Brad Quinn]

I'm at a loss. Is this a problem when deploying the application?

You have gacutil'd the assemblies, right? I sometimes overlook this when
deploying new GAC'd assemblies.

Good luck.

"Amelyan" wrote:

I statically link the assembly to my project and it doesn't implement
IConfigurationSectionHandler. Usually, GAC is the first place where .net
application searches for its assemblies. However, this doesn't seem to be
the case with ASP.NET applications.

Do you know why?

Thanks,
Amelyan

"Brad Quinn" <Br*******@discussions.microsoft.com> wrote in message
news:41**********************************@microsof t.com...

ASP.NET picks up signed assemblies just fine, at least for me it does.

Are you dynamically loading the assembly? If you are, make sure that
you're
using the fully qualified type i.e. Version, Culture and PublicKeyToken.

You'll also want to include this information (in the section element in
the
configSections node) if the GAC'd assembly has a class that implements
IConfigurationSectionHandler.

"Amelyan" wrote:

What is the deal with ASP.NET and signed assemblies? I have experienced
some weird behavior of my web application where it looked like my asp.net
application wasn't even looking into GAC. Then, I saw a brief mention on
the web "ASP.NET doesn't pick up signed assesmblies from GAC".

Does anyone who knows can give more explanation?

Thanks,
Amelyan

[Amelyan]

No, this is not when I deploy the application.

1) I rebuild my strongly signed assemblies.
a) I have a post build step that automatically "gacutils" them after
every build. I verified that it works.
2) I rebuild my WebApplication and run it from Visual Studio.

However, VisualStudio picks up dlls, not from GAC, but from some special
directory C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Tempo rary ASP.NET
Files\ where it seems to cache them. The error I get, lists the version of
assembly that it is trying to load, and that is the version that resides
only in that Temporary ASP.NET Files folder, and nowhere else.

Moreover, sometimes, when I run my WebApplication from VisualStudio it picks
up WebApplication.dll, not from my project's bin, but from that same
temporary Asp.Net Files folder.

Amelyan
"Brad Quinn" <Br*******@discussions.microsoft.com> wrote in message
news:2E**********************************@microsof t.com...

I'm at a loss. Is this a problem when deploying the application?

You have gacutil'd the assemblies, right? I sometimes overlook this when
deploying new GAC'd assemblies.

Good luck.

"Amelyan" wrote:

I statically link the assembly to my project and it doesn't implement
IConfigurationSectionHandler. Usually, GAC is the first place where .net
application searches for its assemblies. However, this doesn't seem to
be
the case with ASP.NET applications.

Do you know why?

Thanks,
Amelyan

"Brad Quinn" <Br*******@discussions.microsoft.com> wrote in message
news:41**********************************@microsof t.com...

> ASP.NET picks up signed assemblies just fine, at least for me it does.
>
> Are you dynamically loading the assembly? If you are, make sure that
> you're
> using the fully qualified type i.e. Version, Culture and
> PublicKeyToken.
>
> You'll also want to include this information (in the section element in
> the
> configSections node) if the GAC'd assembly has a class that implements
> IConfigurationSectionHandler.
>
> "Amelyan" wrote:
>
>> What is the deal with ASP.NET and signed assemblies? I have
>> experienced
>> some weird behavior of my web application where it looked like my
>> asp.net
>> application wasn't even looking into GAC. Then, I saw a brief mention
>> on
>> the web "ASP.NET doesn't pick up signed assesmblies from GAC".
>>
>> Does anyone who knows can give more explanation?
>>
>> Thanks,
>> Amelyan
>>
>>
>>