Can Web App and Winform both access an assembly in the GAC?

[Monty]

Hello,

[VS 2005, Web Application Projects, VB.Net, XP Pro SP2]

I have created a solution which has both a web UI and a winform UI, the
latter is just for administrators. The Web UI (a Web Application Project)
and the winform project both reference the same BLL in a separate assembly,
and I have all three projects in a single solution file for development,
with the two UI's each having a project reference to the BLL assembly. I
created a Setup and Deployment package for the winform app where I add the
BLL assembly to the GAC. When I run this setup application on my development
machine, I begin to experience issues debugging my web app. Specifically, on
a page where I bind a grid to an ObjectDataSource (where the object class is
in my BLL), I get this error message:

The type specified in the TypeName property of ObjectDataSource 'odsItems'
could not be found.

However, it can successfully do plenty of things that depend on calling the
BLL assembly, so it's not like it can't find it. If I uninstall my winform
UI setup package, it begins working fine again. In production, the web
server for the app will have both the Web UI and winform UI installed on it,
and I would like them to both share the BLL assembly in the GAC. Can anyone
point out the error of my ways here? Also, side question, when I've run the
install package and my BLL assembly is in the GAC (and I started having
these issues) I thought "Ah, I'll just remove the 'project reference' to the
BLL from the web app and add a reference to the assembly registered with the
GAC." So I clicked Add Reference --> .Net tab, and I expected that I would
see the BLL assembly listed here, but it is not. What does it take to get a
GAC reg'd assembly to show up here?

TIA,

Monty

 

[Peter Bradley]

Hi Monty,

Firstly, any number of apps of any number of types can access assemblies
that are in the GAC. So this is not the problem you are seeing. IMO it's
probably to do with the strong naming of the assembly. The reference in
both your projects must access the assembly with the same strong name.

As for your side issue, AFAIK you can't specify, directly, where an assembly
will be found. The Framework searches for assemblies in a particular order,
so if there's an assembly in the GAC, it will use that, no matter what you
used when you created the reference. However, as I said above, I think that
the referenced assembly and the assembly in the GAC must have the same
strong name.

HTH


Peter

 

[Monty]

Thanks Peter, I will check on the Strong Name, though I don't know if that's
it because it was able to utilize some aspects of the Assembly. Regarding
the "side question", I'm simply wondering why an assembly I have registered
in the GAC does not show up in the list of assemblies in the ".Net" tab of
the "Add Reference" dialog.

 

[Walter Wang [MSFT]]

Hi Monty,

To make Visual Studio to list your assemblies in the "Add Reference"
dialog, you need to add a registry key to specify the directory where the
assemblies reside:

#How to: Add or Remove References in Visual Studio
http://msdn2.microsoft.com/en-us/library/wkze6zky(VS.80).aspx

For your first question, please check the strong name issue as Peter
suggested and let us know the result. Thanks.


Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Monty]

Hi Peter,

Could you expound on this point?: " The reference in both your projects
must access the assembly with the same strong name."

The assembly is strong-named, of course, and since the strong name is set in
the assembly's properties, and both the UI projects reference the same
assembly project, I'm not sure how they could both be referencing that
project but with ~different~ strong names.

Thanks, Monty

Hi Monty,

Firstly, any number of apps of any number of types can access assemblies
that are in the GAC. So this is not the problem you are seeing. IMO it's
probably to do with the strong naming of the assembly. The reference in
both your projects must access the assembly with the same strong name.

As for your side issue, AFAIK you can't specify, directly, where an
assembly will be found. The Framework searches for assemblies in a
particular order, so if there's an assembly in the GAC, it will use that,
no matter what you used when you created the reference. However, as I
said above, I think that the referenced assembly and the assembly in the
GAC must have the same strong name.

HTH


Peter

Hello,

[VS 2005, Web Application Projects, VB.Net, XP Pro SP2]

I have created a solution which has both a web UI and a winform UI, the
latter is just for administrators. The Web UI (a Web Application Project)
and the winform project both reference the same BLL in a separate
assembly, and I have all three projects in a single solution file for
development, with the two UI's each having a project reference to the BLL
assembly. I created a Setup and Deployment package for the winform app
where I add the BLL assembly to the GAC. When I run this setup
application on my development machine, I begin to experience issues
debugging my web app. Specifically, on a page where I bind a grid to an
ObjectDataSource (where the object class is in my BLL), I get this error
message:

The type specified in the TypeName property of ObjectDataSource
'odsItems' could not be found.

However, it can successfully do plenty of things that depend on calling
the BLL assembly, so it's not like it can't find it. If I uninstall my
winform UI setup package, it begins working fine again. In production,
the web server for the app will have both the Web UI and winform UI
installed on it, and I would like them to both share the BLL assembly in
the GAC. Can anyone point out the error of my ways here? Also, side
question, when I've run the install package and my BLL assembly is in the
GAC (and I started having these issues) I thought "Ah, I'll just remove
the 'project reference' to the BLL from the web app and add a reference
to the assembly registered with the GAC." So I clicked Add Reference -->
.Net tab, and I expected that I would see the BLL assembly listed here,
but it is not. What does it take to get a GAC reg'd assembly to show up
here?

TIA,

Monty

 

[Monty]

Hi Walter,

I'm not exactly sure what Peter meant by "The reference in both your
projects must access the assembly with the same strong name." All three
projects are in the same solution, and both UI projects have a "project
reference" to the same BLL assembly. Why would parts of my Web UI stop
working when I install the winforms client (which registers the BLL assembly
to the GAC)? I should emphasize that I can access items from the referenced
BLL assembly just fine from the WebUI (whether it's in the GAC or not), it
seems to be only when I use a class from the BLL as an ObjectDataSource
TypeName. For instance, if the name of my BLL object is:

MyCompany.MyProduct.MyCommonLib.MyClass

I can do this in my page load with no problem:

Dim o1 As New MyCompany.MyProduct.MyCommonLib.MyClass
Debug.Print(o1.SomeProperty)
o1 = Nothing

But if in my page I have this in my object data source:

TypeName="MyCompany.MyProduct.MyCommonLib.MyClass"

I get this error:

The type specified in the TypeName property of ObjectDataSource
'odsItems' could not be found.

Any ideas on what I'm doing wrong? Here is my full ObjectDataSource code,
which works fine when my BLL assembly is ~not~ registered in the GAC:


<asp:ObjectDataSource ID="odsItems" runat="server" DeleteMethod="Remove"
OldValuesParameterFormatString="{0}"

SelectMethod="GetItemTransactions"
TypeName="MyCompany.MyProduct.MyCommonLib.ItemTransactions"

UpdateMethod="Update" InsertMethod="Add">

<DeleteParameters>

<asparameter Name="ID" Type="Int32" />

</DeleteParameters>

<UpdateParameters>

<asparameter Name="ID" Type="Int32" Direction="InputOutput" />

<asparameter Name="Quantity" Type="Decimal" />

<asparameter Name="AmountPerUnit" Type="Decimal" />

<asparameter Name="LocationID" Type="Int32" />

</UpdateParameters>

<InsertParameters>

<asparameter Name="ItemID" Type="Int32" />

<asparameter Name="Quantity" Type="Decimal" />

<asparameter Name="LocationID" Type="Int32" />

</InsertParameters>

</asp:ObjectDataSource>


Thank you for any assistance you can provide!

Monty

 

[Walter Wang [MSFT]]

Hi Monty,

Please check if you're using auto-increment version in the class library:
check AssemblyInfo.cs:

[assembly: AssemblyVersion("1.0.0.*")]


An asterisk in the version will cause the generated assembly increment in
the build number.

When you install the assembly to GAC, the assembly you used from your
WinForm client and Web application will use the version in GAC instead of
the local copy (if the local copy has the same name/version/public key
token/culture). You can verify this by using Process Explorer
(http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.msp
x) to view modules loaded by your winform client or w3wp.exe (IIS ASP.NET
worker process): select the class library from the module list and view its
property, it should reveal the full path to it.

My guess is that your web site is using the GAC version but also has a
local copy in bin folder which has different version.

Normally I would suggest not to install the assembly into GAC while you're
also compiling it on the same system.

Let me know if this helps.


Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Monty]

Hi Walter,

Thanks, but that does not appear to be the case. My class library has this:

<Assembly: AssemblyVersion("1.0.0.0")>
<Assembly: AssemblyFileVersion("1.0.0.0")>

Also, I am able to access and create the same class from the library just
fine in my Page_Load function, but I just get the error I use it as a
TypeName on my ObjectDataSource. Any other ideas? Thanks.


Monty

 

[Walter Wang [MSFT]]

Hi Monty,

Thanks for the update. I'm still having trouble to reproduce the issue on
my side. I'm wondering if you could send me a simple reproducible project
so that I can reproduce it on my side and help find the root cause? Thanks.


Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter Bradley]

If you recompile and change the version, but don't change the version that
is referenced in the referencing project, you'll get a conflict. I always
delete and recreate references if I recompile the assembly being referenced.
This is probably overkill, but has got me out of trouble several times,
because it's easy to forget that the assembly's hash changes if you
recompile (after changes), so even if the version is the same there could
still be a problem.

I think I should repeat however, because it may have got lost in the
discussion, that where you get your reference from will not affect where the
running program finds the assembly. Since the Framework looks first in the
GAC, it will always try to load from the GAC first. This is often a source
of problems for my developers who may have remembered to change the assembly
in the GAC, but forgotten that the reference in their solution is from
somewhere else (e.g. the file system).

HTH



Peter

Hi Peter,

Could you expound on this point?: " The reference in both your projects
must access the assembly with the same strong name."

The assembly is strong-named, of course, and since the strong name is set
in the assembly's properties, and both the UI projects reference the same
assembly project, I'm not sure how they could both be referencing that
project but with ~different~ strong names.

Thanks, Monty

Hi Monty,

Firstly, any number of apps of any number of types can access assemblies
that are in the GAC. So this is not the problem you are seeing. IMO
it's probably to do with the strong naming of the assembly. The
reference in both your projects must access the assembly with the same
strong name.

As for your side issue, AFAIK you can't specify, directly, where an
assembly will be found. The Framework searches for assemblies in a
particular order, so if there's an assembly in the GAC, it will use that,
no matter what you used when you created the reference. However, as I
said above, I think that the referenced assembly and the assembly in the
GAC must have the same strong name.

HTH


Peter

Hello,

[VS 2005, Web Application Projects, VB.Net, XP Pro SP2]

I have created a solution which has both a web UI and a winform UI, the
latter is just for administrators. The Web UI (a Web Application
Project) and the winform project both reference the same BLL in a
separate assembly, and I have all three projects in a single solution
file for development, with the two UI's each having a project reference
to the BLL assembly. I created a Setup and Deployment package for the
winform app where I add the BLL assembly to the GAC. When I run this
setup application on my development machine, I begin to experience
issues debugging my web app. Specifically, on a page where I bind a grid
to an ObjectDataSource (where the object class is in my BLL), I get this
error message:

The type specified in the TypeName property of ObjectDataSource
'odsItems' could not be found.

However, it can successfully do plenty of things that depend on calling
the BLL assembly, so it's not like it can't find it. If I uninstall my
winform UI setup package, it begins working fine again. In production,
the web server for the app will have both the Web UI and winform UI
installed on it, and I would like them to both share the BLL assembly in
the GAC. Can anyone point out the error of my ways here? Also, side
question, when I've run the install package and my BLL assembly is in
the GAC (and I started having these issues) I thought "Ah, I'll just
remove the 'project reference' to the BLL from the web app and add a
reference to the assembly registered with the GAC." So I clicked Add
Reference --> .Net tab, and I expected that I would see the BLL assembly
listed here, but it is not. What does it take to get a GAC reg'd
assembly to show up here?

TIA,

Monty

 

[Monty]

Hi Walter,

You created a solution with projects of winform, asp.net, a class library
shared between the two, and an installer for the winforms app? And the
ASP.Net project had a grid (or any control) that had an ObjectDataSource
that had a TypeName that referenced a custom object in the shared assembly?
And you ran the winform installer, then ran the ASP.Net app in debug mode
and were able to view grid with no problems? Well first off, thank you for
your efforts. If you still have that test solution, please send it my way
and I will see if I can modify it to either reproduce the behavior. Thanks
again,

Monty

 

[Walter Wang [MSFT]]

Hi Monty,

I've been able to reproduce the issue. Previously I was using a Web Site
instead of a Web Application Project, that's why the issue doesn't occur.
I'm sorry about that.

Please try with a web site on your side to verify if you could also observe
the same behavior.

I'll do some research to see if I could find the root cause and workaround
for the Web Application Project. I'll keep you updated.


Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Walter Wang [MSFT]]

Hi Monty,

When you're using Web Site mode, a private copy of the shared assembly will
be copied to the bin\ subfolder of the web site; while in Web Application
Project mode, the private copy doesn't exist in the bin\ folder.

When you use only the type name in ObjectDataSource.TypeName such as
"myns.ProductDAO", it will not be able to use the version installed in GAC.
In web site mode, since there's a private copy, it will actually use the
private copy instead of the version in GAC.

The fix is to use a full name of the assembly such as:

TypeName="myns.ProductDAO, ClassLibrary1, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=15fcff621830baf6"

Hope this helps.


Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Monty]

Awesome sleuthing, thanks Walter. Is there a quick way of finding the fully
qualified name of a class in an assembly (including the PublicKeyToken,
etc)? Thanks again.

 

[Walter Wang [MSFT]]

Hi Monty,

You can use gacutil.exe from .NET Framework SDK:

gacutil /l ClassLibrary1


Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.