Try putting the strong name of the controls assembly into the config file so
that it gets included when the pages are compiled. Then you don't have to
put the strong name of the assemblies into the pages themselves.
<system.web>
<compilation>
<assemblies>
<add assembly="yourassemblystrongnamehere" />
</assemblies>
</compilation>
</system.web>
This adds the assembly in when your aspx and ascx compiles. The strong name
will force the assembly to looked up in the GAC so it won't have to be
deployed locally.
HTH,
Matt
-----Original Message-----
From: Jon Flanders [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 19, 2003 12:01 PM
To: [EMAIL PROTECTED]
The fully qualified assembly name should be know at deploy time - why would
you need to parse the aspx files?
-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ranjan
Sent: Friday, July 18, 2003 9:52 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] DLLs and GAC and ASP.Net
yup, i did change that last night, it worked.
now my problem is, who will do that
when im going to deploy, shall i wrte some file parsing tool or something???
r.
-----Original Message-----
From: Jon Flanders [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2003 10:57 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] DLLs and GAC and ASP.Net
I wouldn't mind seeing the exact error message but my guess is your
@Register directives don't have the fully quallifed assembly name (this
could be true of the code behind dll as well - in terms of the inherits tag
of the @Page directive.
-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ranjan
Sent: Friday, July 18, 2003 3:05 AM
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] DLLs and GAC and ASP.Net
ASP.Net project.
Project Scenario :::
Application DLL refers 9 Interop DLLs
Code Behind DLL refers Application DLL and 1 Interop DLL .
UI Controls DLL refers Application and Code Behind DLL .
These 12 DLLs, along with ADODB 2.6.0.0 (only this version is used
throughout)are strong named, and put in the GAC. and refered to by the
ASP.Net Web Application.
When compiled, the ASP.Net Web Application does not give any problem.
When it is posted on the IIS, and the URL hit, it says UI Controls
DLL(called CommonControls.dll) cannot be loaded.
Error Messages(using FusLogVW.exe)
LOG: Processing DEVPATH. LOG: DEVPATH is not set. Falling through to regular
bind.
LOG: Policy not being applied to reference at this time (private, custom,
partial, or location-based assembly bind). LOG: Post-policy
reference: CommonControls
When this DLL is copied to the bin folder of the ASP.Net Web Application
it says, the Code Behind DLL is not refernced.
When this DLL is copied too, to the bin folder that is, the ASP,Net Web
Application works just fine. This means that the Application DLL in the GAC
works fine.
Now when i remove the 2 DLLs i copied before, the Web Application continues
to work nice and cozy. (this may be because of the fact that these DLLs
would have been copied to the Temp folders , and even when i have removed
the actual copy, runtime will refer to the second copy. I have imported and
strong named the interops using TLBIMPORT and SN. Used GACUTIL for Gaccing.
Also, i have tried doing this on 2 machines, XP and Server 2003.
any help??
r.
