Make friend class visible to another assembly

Hi all,

I have written a test class in an assembly. It is a friend class and I would like it to be visible to another assembly. The class is as follows:


Imports System.Runtime.CompilerServices

<Assembly: InternalsVisibleTo("T01_BLL")>
Friend Class Class1

    Public Function HelloWorld() As String

        Return "Hello World"

    End Function

End Class

the problem I have is that when I add another class to the assembly, it is also visible to the other assembly.

Is there a way to get the single class to be visible and not all classes of the assembly?

Any help is greatly appreciated.

Thanks.
resourcesysAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

pedros7Commented:
You'll need to set the class as public.

That should work. The keywords Private, Friend and Public are the following:
Private – within the same module, class, or structure.
Friend – within the same assembly.
Public – anywhere in the same project, from other projects that reference the project, and from any assembly built from the project. In other words, any code that can find it.

Regards
0
pedros7Commented:
Use the keywords above per class accordingly:
Public Class Class 1{}
Private Class Class 2{}

Regards
0
pedros7Commented:
Sorry, just re-read:

If you want to restrict the view to another asembly only, there are a few alternatives:
. set the other class members as private... but that means they are also private to each other within the same assembly

. the assembly attribute InternalsVisibleToAttribute can be used multiple times, hence, using a 3 assembly structure, you could have: AssemblyA, AssemblyB and AssemblyC
AssemblyB would include the common classes (as in your example above), and with the InternalsVisibleToAttribute set twice to allow visibility to AssemblyA and AssemblyC (where you'd put the rest of your classes).

Hope this helps.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

resourcesysAuthor Commented:
Hi pedros7,

Thank you for your responses.

The sturcture of the test application i wanted to develop would be a data access layer assembly (DAL), a business logic layer assembly (BLL), and a website.

The website would interect with the BLL and the BLL would interact with the DAL.

I don't think I'm going to be able to achieve this, although I could have a seperate assembly just for the database object, that way, the database could be seen by the DAL, the DAL could be seen by the BLL, and the BLL could be seen by the website.

I think that would would work.

I wanted the DAL to be visible to BLL only, InternalsVisibleTo would do this, but I wanted a database class in the DAL to be visible only within the DAL.
0
resourcesysAuthor Commented:
Sorry, the last message should read as:

Hi pedros7,

Thank you for your responses.

The sturcture of the test application i wanted to develop would be a data access layer assembly (DAL), a business logic layer assembly (BLL), and a website.

The website would interect with the BLL and the BLL would interact with the DAL.

I wanted the DAL to be visible to BLL only, InternalsVisibleTo would do this, but I wanted a database class in the DAL to be visible only within the DAL.

I don't think I'm going to be able to achieve this, although I could have a seperate assembly just for the database object, that way, the database could be seen by the DAL, the DAL could be seen by the BLL, and the BLL could be seen by the website.

I think that would would work.
0
pedros7Commented:
Now, with the added detail, it makes more sense to me now.
You'd always want to maintain the layer independecy to keep the OO abstraction between the web layer and the data layer. (I'd use namespaces as well to segregate the different components e.g. Employees, HelperClass.)

To be honest, the classes, they can all be public! As public is only within your project!
If you specifically want to hide them by making the classes Friend, then you'd use as you say the 'cascading' assemblies. Just bear in mind,the web site pages could be in multiple assemblies!!
To bypass this and still retain the benefit of stopping web site calls to the DAL, then you can make the DAL as Friend with attribute to allow DLL, and make DLL Public so the web site pages have access to it.

Example on a web site/page to return an employees related information:
Web page with a gridview using a object datasource to show a list of employees
The object datasource would target the Staff Class, method getEmployees(minimumSalary, maximumSalary).
(If you don't want to use a grid view and object data source, your web page can just have a method that calls the getEmployees, iterates through the list and creates a div structure, UL or html table to display in the page, perhaps within a placeholder..)
Employee Class (Public)
A class with just private variables and properties to populate them. Simple constructor but no methods generally. This would hold a employee

StaffDataClass (Friend, in assembly  with attribute to allow DLL to see these type of classes)
the Data layer would include methods that the StaffClass DLL map to: e.g. getAllEmployeesData(), getEmployeesData(minimumSalary, maximumSalary) getEmployeeData(ID) these execute SQL stored procedures and return recordsets.

Staff Class (Public)
this would include a variables, properties and methods to gather a list of items of type employee. To get the items, methods such as getAllEmployees(), getEmployees(minimumSalary, maximumSalary), getEmployee(ID) mapping to the respective DAL methods. The BLL methods would iterate through the results of the record set, create a new employee object, populate with details from DAL and add to a list of type employee, which would then be returned to the web page.

Hence, the web site cannot see the classes in the DAL assembly and must go though the DLL. This approach, as I mentioned, would stop any slip-ups in accessing the DAL directly from the web site?
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
pedros7Commented:
Including the hiding of the database portion of the DAL:
DAL (for database) - Friend Allows DAL (general)
DAL (general) - Friend Allows DLL
DLL - Public for web site to access

Regards
0
resourcesysAuthor Commented:
Question answered
0
resourcesysAuthor Commented:
Thanks pedros7.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.