0

I'm having a hard time making this work.

The 3 classes FooType, WebApp & IWebApp must not be accessbile \ visible outside of this DLL. So hence the sealed & internal classes.

Issues I'm having are ...

1) In WebApp class, FeeType1 is not accessible in RouteOneBuilder method's parameter.

2) In WebApp class, FeeType1 is not accessible \ visible in switch's case-statement. (need to be visible).

3) In WebApp class, CreditApplication of FeeType1 property is not visible in the switch's case-statement (need to be visible).

Is there a better way to this complicated script? Am I already screwed for exposing classes outside of this DLL? Can all of step 1 to 4 be resolved differently (or be fixed somehow)?

I don't see how can I make this any simplier.

internal static class FooType
{
    public class FeeType
    {
        public FeeType() { }
        public string CreditApplication = "Credit Application";
        public string CreditVehicle = "Credit Vehicle";
    }
    public FeeType FeeType1
    {
       get { return new FeeType(); }
       private set { }
    }
}    
sealed class WebApp : IWebApp
{
    public string RouteOneBuilder(FooType.FeeType1 typing)
    {
       var xml = "";

       switch(typing)
       {
           case FooType.FeeType1.CreditApplication:
               xml = "asdf";
               break;
           default:
               throw new Exception("Unknown value");
       }

       return xml;
    }
}
internal interface IWebApp  
{
    string RouteOneBuilder(FooType.FeeType typing);
}
Joe Hawkins
  • 9,803
  • 2
  • 21
  • 28
fletchsod
  • 3,560
  • 7
  • 39
  • 65
  • so, are all these classes & interfaces in the same source file? – Mike Nakis Aug 11 '17 at 18:41
  • 3 seperate CS files but all in one same project file (1 DLL file). – fletchsod Aug 11 '17 at 18:42
  • And what about namespaces? Are in the same namespace or different namespaces? – Mike Nakis Aug 11 '17 at 18:43
  • 1
    Well the `IWebApp` interface is visible because you've added `public` to it, did you mean the class `WebApp` is visible outside the class? – AJD- Aug 11 '17 at 18:43
  • Same namespace for all 3 files (Actually all files in 1 project use same namespace). – fletchsod Aug 11 '17 at 18:45
  • It does not make any sense that something becomes invisible within the same assembly just because you declared it `internal`. So, there may be something seriously wrong with your solution / project files. – Mike Nakis Aug 11 '17 at 18:48
  • The purpose of `internal` & `sealed` is to prevent the classes from showing outside of this DLL project. `static` class use `internal`, `sealed` doesnt work with `static` class. – fletchsod Aug 11 '17 at 18:49
  • What *exactly* happens when you make `IWebApp` internal and try to build? What is the exact error? – Kyle Aug 11 '17 at 19:08

2 Answers2

1

Your definition of a sealed class is incorrect. It is not an access modifier like public, private, protected and internal. Marking a class sealed only says that it cannot be inherited from; it does not say anything about access per se.

From the MSDN documentation:

When applied to a class, the sealed modifier prevents other classes from inheriting from it.

That means that you can still provide a public class that is sealed. However, if you try to inherit from a sealed class, you will receive a compiler error like this:

cannot derive from sealed type 'YourNamespace.YourSealedClass'.


Also, I suggest you read this and this regarding internal/public and nested classes.

Now, looking at the code you provided, the following compiler errors pop up:

FooType.FeeType1': cannot declare instance members in a static class

This error means that if the class is declared static, all of the members must be static too.

FooType.FeeType1' is a 'property' but is used like a 'type'

This arises from the fact that the class is static but none of the members are.

Inconsistent accessibility: parameter type 'FooType.FeeType' is less accessible than method 'IWebApp.RouteOneBuilder(FooType.FeeType)'

The return type and each of the types referenced in the formal parameter list of a method must be at least as accessible as the method itself.

You can find more information about the last error here.

M3talM0nk3y
  • 1,382
  • 14
  • 22
1

The design is not correct.

If a type is marked as internal this indicates that it should never be accessed outside of its DLL. If this type must be accessed outside of the DLL in which it is declared, it should not be marked internal.

What constraint is preventing you from using a public modifier or from including the types in the same DLL as the consuming code?

In certain cases it is useful for external DLLs or EXEs to view internal members declared in another DLL. One notable case is for unit testing. The code under test may have an internal access modifier, but your test DLL still needs to access the code in order to test it. You can add the following to AssemblyInfo.cs of the project containing the internal members to allow external access.

[assembly:InternalsVisibleTo("Friend1a")]

See InternalsVisibleToAttribute Class for more details.

Side note: The sealed access modifier doesn't prevent access from outside of the declaring DLL. It prevents other types from extending the type.

Joe Hawkins
  • 9,803
  • 2
  • 21
  • 28