InternalsVisibleTo for Web Project

[gzinger]

I have an assembly with some internal methods that I have to access from my
web service. I learned that I can use “InternalsVisibleTo� to enable such
access. Since I have control over both the class library project (with the
internal stuff) and the web project it seems that the scenario is possible.
However, the problem seems to be with the web service project being a web
project.
I followed all possible documentation and postings to create, sign and make
assemblies friendly. If I try to consume my class library (with internal
types) from a windows application (which was made trusted) everything works
perfectly as expected. If, however, I try to use it from within my web
project I get errors that the internal types and methods from the class
library are not visible:

Error 12 'EPHandl.Vault.PaymentVault' is inaccessible due to its protection
level c:\inetpub\wwwroot\epService\App_Code\CCProcessor. asmx.cs 111 13 http://localhost/epService/
Error 13 'EPHandl.Vault.PaymentVault' does not contain a definition for
'GetCreditCard' c:\inetpub\wwwroot\epService\App_Code\CCProcessor. asmx.cs 111 26 http://localhost/epService/

Here is how I indicated that I trusted the web project from the class
library project:
[assembly: InternalsVisibleTo("App_Code,
PublicKey=0024000004800000940000000602000000240000 525341310004000001000100dd31afb809fb4cdaa134816a2d badca223b0df0fffe8cf82842b5b848c2d51fb71a7f5b71273 328d26d48faa8351e905105a5cb9b5103c442cbc20765e8404 225b0ffac98dfe04de6536d5ccad16d3bb05791e9be1c8fedc 65d3e77253aedff6f21d6d69dfb6cad9ffc4c4be8e752951ed 6fd126f8c4df8c56457b2c38163ec4")]
I understand that the way web project is implemented in VS2005, it is not
fully compiled and signed until later point, so how can the
InternalsVisibleTo attribute be used to point to web projects’ assemblies?
There has got to be a way.

Thanks.

--
http://www.zbitinc.com

[Steven Cheng[MSFT]]

Hi Gzinger,

Welcome to the ASPNET newsgroup.

As for the InternalsVisibleTo attribute, it requres us to provide the
assembly's filename or optionally the strong-name token to idenitity the
assembly we allow to access internal class or type. However, for ASP.NET
2.0, it adopts the new dynamic compilation model, the assemblies' name is
randomly generated, it'll be hard for us to provide a fixed name for them.
Yes, there does exists some helper project or add-on can help do the
precompilation and make the pages or App_Code classes be compiled into
fixed name assemblies, however, we're still not recommended to use the
InternalVisibleTo attribute with such mangled assembly name. IMO, you can
consider creating a separate class library project and put the code which
need to access the target assembly's internal data there. And in the target
assembly, you add the "InternalsVisibleTo" attribute against this class
library assembly. Thus, we can use this class library in our ASP.NET web
application. How do you think of this?

Regards,

Steven Cheng
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.

[gzinger]

Dear Steven Cheng,

Thank you for your response. I already thought about the approach that you
suggested where an intermediate library that is trusted by the “internal
code� basically wraps it up exposing those internal types and methods to the
outside world. Besides that approach being not very elegant, my main concern
is that once we open that back door we can not control who is going to
enter/exit trough it, which essentially defeats the purpose of the whole
architecture. I understand that I would have to go with this approach if you
are saying that there is no the proper way, but I am very reluctant to do
this. I just want to make sure that I understand you correctly – are you
really saying that InternalsVisibleTo paradigm does not apply to web project
assemblies?
I also would like to get more information on the other approach that you
mentioned – namely “helper project or add-on can help do the precompilation
and make the pages or App_Code classes be compiled into fixed name
assemblies�. I understand that you do not recommend this approach but I still
would like to know what are the challenges and tradeoffs. Could you please
elaborate on the subject a bit more? Perhaps point out the exact tools I can
use?

--
http://www.zbitinc.com
"Steven Cheng[MSFT]" wrote:

Hi Gzinger,

Welcome to the ASPNET newsgroup.

As for the InternalsVisibleTo attribute, it requres us to provide the
assembly's filename or optionally the strong-name token to idenitity the
assembly we allow to access internal class or type. However, for ASP.NET
2.0, it adopts the new dynamic compilation model, the assemblies' name is
randomly generated, it'll be hard for us to provide a fixed name for them.
Yes, there does exists some helper project or add-on can help do the
precompilation and make the pages or App_Code classes be compiled into
fixed name assemblies, however, we're still not recommended to use the
InternalVisibleTo attribute with such mangled assembly name. IMO, you can
consider creating a separate class library project and put the code which
need to access the target assembly's internal data there. And in the target
assembly, you add the "InternalsVisibleTo" attribute against this class
library assembly. Thus, we can use this class library in our ASP.NET web
application. How do you think of this?

Regards,

Steven Cheng
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.

[Steven Cheng[MSFT]]

Thank you for the response Gzinger,

Yes, I can understanding your concern on this. Using an additional class
library may not be quite elegant. As for the ASP.NET 2.0, we can produce
precompilation on the website, you can see the precompile options when
select the "Build-->Publish WebSite" menu. Also, ASP.NET team provide a new
"web deployment project" which can help us do more customization on the
precompiled assembly of the web project:
#Visual Studio 2005 Web Deployment Projects (Beta V2 Preview)
http://msdn.microsoft.com/asp.net/re...p/default.aspx

For example, it can help the pages or components in different folder be
compiled into separate assemblies and the assembly name can adopt a fixed
naming rule.

However, I'm not quite sure whether there is any problem if we use
"InternalsVisibleTo" attribute against such precompiled assembly. If you
do not feel very very urgent, I will discuss this issue with some other
ASP.NET experts to confirm this. I'll update you as soon as I got any
update.

Thanks for your understanding.

Regards,
Steven Cheng
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.

[gzinger]

Dear Steven Cheng,

Yes, please find out more information on the other options from your ASP.NET
experts and please let me know.

Thanks.

--
http://www.zbitinc.com
"Steven Cheng[MSFT]" wrote:

Thank you for the response Gzinger,

Yes, I can understanding your concern on this. Using an additional class
library may not be quite elegant. As for the ASP.NET 2.0, we can produce
precompilation on the website, you can see the precompile options when
select the "Build-->Publish WebSite" menu. Also, ASP.NET team provide a new
"web deployment project" which can help us do more customization on the
precompiled assembly of the web project:
#Visual Studio 2005 Web Deployment Projects (Beta V2 Preview)
http://msdn.microsoft.com/asp.net/re...p/default.aspx

For example, it can help the pages or components in different folder be
compiled into separate assemblies and the assembly name can adopt a fixed
naming rule.

However, I'm not quite sure whether there is any problem if we use
"InternalsVisibleTo" attribute against such precompiled assembly. If you
do not feel very very urgent, I will discuss this issue with some other
ASP.NET experts to confirm this. I'll update you as soon as I got any
update.

Thanks for your understanding.

Regards,
Steven Cheng
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.

[Steven Cheng[MSFT]]

Sure, I¡¯ll update you as soon as I get any further info.

Regards,

Steven Cheng
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.

[Steven Cheng[MSFT]]

Hi Gzinger,

I've just got some further feedback from other dev and consultant guys and
it seems that so far there is no other better means and they also recommend
use a separate class library to do this. Here is the original description
from them:

==================================
in my opinion no assembly should have any references to a Web Site
assembly, because this strongly implies a flaw in your overall
architecture. In layered architectures, no layer should have any dependency
on another layer higher on the stack. InternalsVisibleToAttribute doesn¡¯t
violate this by itself, but it opens the door for all kinds of undesirable
dependences. A Web Site is also a very awkward vehicle to promote reuse.
Reusable stuff in the web UI layer is better kept in a regular class
library.

My 2 cents
===================================

Thanks for your understanding.

Regards,

Steven Cheng
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.

[gzinger]

Thanks. I am alredy doing what is suggested.

The only other thing on which I disagree with your collegue is that
InternalsVisibleTo is not a useful paradim for the web projects (even if
there was a way to utilize it, that is). Please remember that the sole
purpose of a web project COULD BE to host web services. In such case if one
would like to separate out business logic, but putting it in a distinct class
library, InternalsVisibleTo would come very handy.

Thanks.
--
http://www.zbitinc.com
"Steven Cheng[MSFT]" wrote:

Hi Gzinger,

I've just got some further feedback from other dev and consultant guys and
it seems that so far there is no other better means and they also recommend
use a separate class library to do this. Here is the original description
from them:

==================================
in my opinion no assembly should have any references to a Web Site
assembly, because this strongly implies a flaw in your overall
architecture. In layered architectures, no layer should have any dependency
on another layer higher on the stack. InternalsVisibleToAttribute doesn¡¯t
violate this by itself, but it opens the door for all kinds of undesirable
dependences. A Web Site is also a very awkward vehicle to promote reuse.
Reusable stuff in the web UI layer is better kept in a regular class
library.

My 2 cents
===================================

Thanks for your understanding.

Regards,

Steven Cheng
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.

[Steven Cheng[MSFT]]

Thanks for your followup Gzinger,

Yes, you're right that when the ASP.NET application used to host webservice
it will a bit painful to have this problem. So currently I do admit that
this is an exist problem due to the dynamic compilation model. You can also
submit this on the MSDN product feedback center :

http://lab.msdn.microsoft.com/produc...k/default.aspx

Thanks for your understanding.

Regards,

Steven Cheng
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.

[Joerg Jooss]

Thus wrote gzinger,

Thanks. I am alredy doing what is suggested.

The only other thing on which I disagree with your collegue is that
InternalsVisibleTo is not a useful paradim for the web projects (even
if there was a way to utilize it, that is). Please remember that the
sole purpose of a web project COULD BE to host web services. In such
case if one would like to separate out business logic, but putting it
in a distinct class library, InternalsVisibleTo would come very handy.

Why? It's exactly the same story... you might introduce a dependency from
your business logic to some technical infrastructure, i.e. the web services
assembly. And once that has happened, the two are tightly coupled.

Cheers,
--
Joerg Jooss
ne********@joergjooss.de