none
C# assembly using in VC++ projects (A,B). How to restrict RRS feed

  • Question

  • Hi,

    I want to design one C# assembly which is going to have 50 winform screens. This assembly is going to use in different existing  VC++ projects.(say A,B) by different teams.
    Here is the scenario:
    A project is going to use 25 winforms and B project is going to use other 25 winforms.
    My questions are:
    1. If I give C# assembly, All teams can access all 50 winforms. Is there any way to restrict  'A' team can use only 25 winforms and 'B" team can use remaining 25 winforms. Ofcourse, it is possible by deviding the 25 winforms in to one assembly and 25 winforms in to another assembly, But I want to include all the winforms in to one assembly only.

    2.  Assume Project 'A' uses 25 forms.  With the user whose logged in to the application 'A', i need to disable /enable couple of buttons on couple of winforms. In the same for Application 'B'.. How to acheive this.

    Your suggestions will be appreciated.

    Thanks,
    Rao 
    Thursday, March 11, 2010 6:01 PM

All replies

  • an interresting question

    because neither project A or B are using a 'shared ' windows form in the assembly, but rather each project has its own set of 25, what would be the reason to place all 50 in the one assembly in the first place?

    you could do some fancy security link demand or some sort of 'login' concept, or perhaps even passing a token to the assembly, but i feel all this will do is lead to unwanted complexity .  perhaps the best thing to do is to create 2 assemblies - one for each project (A & B ) in this case.

    if in your assembly there is common code that the forms use, perhaps consider placing that into an additional class library - thus making a total of 3 assemblies.

    assemblyA.dll
    assemblyB.dll
    shared.dll


    let me know if this does not quite match what you have in mind

    Micky D
    Saturday, March 13, 2010 8:58 AM
  • I dont think so at compile time you will be able to do this. However at runtime there may be several solutions.
    Saturday, March 13, 2010 3:35 PM