Re: internal interfaces - C# Discussion Boards

17-Jan-05 6:28

Yes File.Exists works on UNC paths and yes you have to grant permissions on that directory to whatever user context is running your code (or impersonate another user who already has permissions).

The ASPNET (the default account for ASP.NET) won't typically work, however, because it's a local user account. You need to either grant read permissions on the parent directory to Everyone (not necessarily List permissions, though) or change your machine.config file or the Web.config file in the application root to use a domain user account and password (be sure that you secure the Web.config file and don't index it if you configure the user in that file.

Depending on what you're doing, you could also impersonate whatever user is making the request by setting the <identity> configuration element data correctly (see the SDK documentation) and using NTLM authentication on the directory with no anonymous login enabled. There is documentation about how to do this in the .NET Framework SDK along with the documentation for the <identity> configuration element. If you're familiar with IIS and configuring ASP.NET this is not a problem.

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

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles] [My Blog]

internal interfaces

emission17-Jan-05 2:27

17-Jan-05 2:27

Hi!

I'm writing a wrapper assembly for an interop assembly that's not very nicely implemented. The interop is wrapping a COM object that was primarily meant to work with VBScript, and many methods return untyped values, although they could indeed return them typed.

Almost all classes in the assembly have the following structure

<br />
<br />
internal interface IBaseObject<br />
{<br />
   //returns the untyped, wrapped object<br />
   object baseobject{get;}<br />
}<br />
<br />
public class WrappedSomething : IBaseObject<br />
{<br />
   private InteropSomething _baseobject;  <br />
   public WrappedSomething(InteropSomething baseObject)<br />
   {<br />
      _baseobject=baseObject;<br />
   }<br />
   public object baseobject<br />
   {<br />
      get{return _baseobject;}<br />
   }<br />
}<br />

The IBaseObjct interface is there to make it easy to pass these wrapped objects around inside the assembly, and give easy access to the wrapped object.

Of course this works just fine, but I don't like the fact that the classes exposes the property baseobject publicly. I don't want to give other assemblies access to the wrapped object. At least not as easily as it becomes when the property is public.

I could of course solve it by inheriting an internal class, but quite a few of the classes benifits greatly from inheriting other common (publi) functionality from other classes, and since there is no multiple inheritance....

Any suggestions?

Wouldn't is be viable to have the option to implement internal interfaces' methods internal only?

<br />
internal interface ISomething<br />
{<br />
  int DoInternalStuff();<br />
}<br />
<br />
public class Dog : ISomething<br />
{<br />
  internal int DoInternalStuff()<br />
  {<br />
    ///DO stuff<br />
  }<br />
}<br />

Since the interface is internal, I can't see any problem with declaring the implementing methods internal as well.

leppie17-Jan-05 4:36

leppie

17-Jan-05 4:36

Implicit interfaces:

object IBaseObject.baseobject
{
  get{return _baseobject;}
}

^{top secret
Download xacc-ide 0.0.3 now!
See some screenshots}

emission17-Jan-05 6:15

17-Jan-05 6:15

Thanks, I thought I had tried that, but obviously I hadn't..

However, it's not quite there yet.

If i use

<br />
object IBaseObject.baseobject<br />
{<br />
  get{return _baseobject;}<br />
}<br />

I can't access baseobject directly. E.g

<br />
public void DoStuff(Dog Victim)<br />
{<br />
  DoInteropStuff(Victim.baseobject);<br />
} <br />

This results in :

'Dog' does not contain a definition for 'baseobject'

Instead I have to write

<br />
public void DoStuff(Dog Victim)<br />
{<br />
  DoInteropStuff(((IBaseObject)Victim).baseobject);<br />
} <br />

And, although I'm not sure, it seems that could lead to undesirable boxing/unboxing. Maybe it doesn't. I also find it strange that baseobject now becomes effectively internal, but I can't expose it as being internal.

Heath Stewart17-Jan-05 6:41

17-Jan-05 6:41

emission wrote:
And, although I'm not sure, it seems that could lead to undesirable boxing/unboxing. Maybe it doesn't. I also find it strange that baseobject now becomes effectively internal, but I can't expose it as being internal.

Boxing and unboxing[^] describes the process where value types (eg, structs, primitives, and enumerations) are wrapped in objects or vice versa, basically. Read the link for more details.

Unless Victim is a value type (highly unlikely, especially in COM) there is no risk of boxing or unboxing - only conversion.

If you want to truly limit assembly access to a member or class, then learn to utilize the security infrastructure of .NET: Code Access Security[^].

If you want to limit access to a single assembly, you would attribute your member like so (declaritive security):

[StrongNameIdentityPermission(SecurityAction.Demand, Name="MyAssembly", PublicKey="0123456789abcdef")]
object baseobject
{
  get { return _baseobject; }
}

Where Name is your assembly name and PublicKey is your hex-encoded, 16-character public key (which you can get for your assembly in many ways). If you do not strong name your assembly than you have no security. The public key token is derived from your private key used to sign the assembly. If you don't sign the assembly and don't keep your private key private then anyone can spoof your permission demand.

If you want to allow all your assemblies access to the member, then just specify the PublicKey field and use the same key to sign all your assemblies (this is typical for a single organization anyway).

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

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles] [My Blog]

emission17-Jan-05 10:02

17-Jan-05 10:02

Thank you for enlightening me on the boxing issue. Now I know what that means.

Is there no overhead when converting, i.e using ((IBaseObject)Dog).baseobject instead of directly accessing a public Dog.baseobject?

Heath Stewart wrote:
If you want to truly limit assembly access to a member or class, then learn to utilize the security infrastructure of .NET: Code Access Security

Yes, I've studied this issue, after reading an article in MSDN Magazine, and this may very well be of interest in some projects. However, this time it's more a design issue than a security issue, and I just curiously wonder about the reasons behind.

I think that it would be logical that with interface

<br />
internal interface IAnimal<br />
{<br />
   int Age{get;}<br />
}<br />

...a class like this

<br />
public class Dog : IAnimal<br />
{<br />
   internal int IAnimal.Age<br />
   {<br />
      get {return 1};<br />
   }<br />
}<br />

..would be quite enough to satisfy the interface contract. In fact I think it satifies the contract more clearly than

<br />
public class Dog : IAnimal<br />
{<br />
   int IAnimal.Age<br />
   {<br />
      get {return 1};<br />
   }<br />
}<br />

...does.

Since I'm obviously wrong I would like to be corrected, so that I can understand the reasoning behind this.

Heath Stewart17-Jan-05 10:52

17-Jan-05 10:52

emission wrote:
Is there no overhead when converting, i.e using ((IBaseObject)Dog).baseobject instead of directly accessing a public Dog.baseobject?

Negligable. A cast is an instruction that must be processed but compared to boxing operations these are trivial.

emission wrote:
However, this time it's more a design issue than a security issue, and I just curiously wonder about the reasons behind.

No one said that CAS has to be used only for security. Even the term "security" is rather loose. If security means that you don't want other developers via their assemblies to "see" or even access the member than CAS is what you want. Even with explicit interface implementations (i.e., what you're currently doing) a coder merely has to cast to the interface. Even if you used the BrowsableAttribute or EditorVisibilityAttribute you're only hiding it. The only way to truly deny access to the member is CAS.

In .NET 2.0 a new attribute - InternalsVisibleToAttribute[^] - allows compilers to compile code that accesses internal members from another assembly.

emission wrote:
internal int IAnimal.Age

That would be a voilation. Besides, when you compile this the member is actually private, much more strict than your internal access modifier. The thing is that your object must be cast to an interface object on which the member is truly called, which must be public. The interface object references your object, however, so your private member is not access directly.

You can learn more about implicit and explicit interfaces at http://msdn.microsoft.com/library/en-us/csspec/html/vclrfcsharpspec_13_4_1.asp[^] (C# Language Specification).

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

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles] [My Blog]

emission17-Jan-05 12:30

17-Jan-05 12:30

Thanks! The Language Specification cleared things up.

The solution I'll use is (now that I realize that I can have both an explicit implementation of the interface and a non-interfaced member.

<br />
object IBaseObject.baseobject<br />
{<br />
	get<br />
	{<br />
		return _baseobject;<br />
	}<br />
}<br />
<br />
internal object baseobject<br />
{<br />
	get<br />
	{<br />
		return _baseobject;<br />
	}<br />
}<br />

debugging diabled

Member 166075017-Jan-05 2:25

Member 1660750

17-Jan-05 2:25

Debugging has been diabled for the c# web projects. How can i enable debugging?

Re: debugging diabled

Heath Stewart17-Jan-05 7:11

Creating ms installer with V. C#

17-Jan-05 7:11

It would actually be disabled for ASP.NET projects (when compiled, the source language hardly matters which is the whole point of the Common Language Infrastructure, or CLI).

While this belongs in the ASP.NET forum I'll direct you this time to http://support.microsoft.com/search/default.aspx?catalog=LCID%3D1033&query=debugging+ASP.NET+web+applications[^], which describes many differents reasons that is is disabled and how to re-enable it.

In the future, please direct all ASP.NET-related questions to the ASP.NET forum.

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

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles] [My Blog]

basbous17-Jan-05 2:13

basbous

17-Jan-05 2:13

Hello,

Does anyone know how to create an MS installer of V. C# application from another V. C# application (when I click on a btton, the MS Installer of the other application is created).

Please Help.

Re: Creating ms installer with V. C#

Heath Stewart17-Jan-05 6:46

Listing a files in a client directory

17-Jan-05 6:46

Why would you have one install create another? Please explain exactly what it is you're trying to do.

If you're question is simply about how to create a Windows Installer package (MSI) using VS.NEt, read Introduction to Windows Installer[^] in the VS.NET product documentation and follow the links in the table of contents.

For more in-depth information as well as how to manually edit the MSI package using Orca (a tool within the MSI SDK), see the MSI SDK documentation online at http://msdn.microsoft.com/library/en-us/msi/setup/windows_installer_start_page.asp[^].

Note that the installer projects in VS.NET are very limited.

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

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles] [My Blog]

Anonymous17-Jan-05 2:10

Anonymous

17-Jan-05 2:10

Debugging for my c# projects has been diabled. How can I enable the projects for debugging?

Re: C#

johnhebert17-Jan-05 4:42

johnhebert

17-Jan-05 4:42

1. In VS.NET, open the Build menu, select Configuration Manager, then change the Configuration column value for your project to Debug.
2. Find and then completely read a good tutorial on using VS.NET. Smile | :)

Here's a good start:
http://www.learnvisualstudio.com

John Hebert
Solvitur Ambulando

Sree7417-Jan-05 1:46

Sree74

17-Jan-05 1:46

Hello boarders,

How to list a files in a particular directory at the client side?
I need to give a user interface to access the files of a particular folder by using windows user control in a web page.

Any help would be highly appreciated

Thanks,

Sreenath

Re: Listing a files in a client directory

Heath Stewart17-Jan-05 6:52

Re: Listing a files in a client directory

17-Jan-05 6:52

It's really a matter of permissions. Code Access Security grants assemblies based on their evidence a certain set of permissions or unlimited access. You need to make sure that users grant such permissions to your assemblies using certain host-based evidence (assembly evidence besides strong-name identities are not supported for Internet-deployed assemblies), which you can do using a Windows Installer package to execute an Installer class derivative you would define to create a code group, or give them a batch file to run caspol.exe (depending on your confidence in the users' abilities).

For more about this and about scripting controls (in order to easily provide feedback in the web page itself) see an old article of mine at http://www.devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=388[^].

If you have any questions about that article continue them on this thread since I haven't used that site - and don't plan to - in many years.

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

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles] [My Blog]

Member 37818918-Jan-05 4:04

Member 378189

18-Jan-05 4:04

Stewart,

I got the solution. Thanks for your valuable input. I appreciate it.
I recreated windows control library and added URL as an evidence with permission such as FileIO and Assembly execution. It is working perfectly.

Now I need to give msi file to the client. This msi file should create a code group and permission set. Any idea of how to use the installer package? with the installation it should have created necessary code groups and permission sets.

Sreenath

Reading local file on the client side

Sreeanth17-Jan-05 1:37

Sreeanth

17-Jan-05 1:37

I have created a windows control library which contains several form controls. This libaray is being registered on the web page using <object> tag
Eg.,
<OBJECT id=HelloWorldControl1 classid="http://localhost/NBCCtrlLib/NBCControlLib.dll#devhood.rtfcontrol" VIEWASTEXT width=500 height=500></OBJECT>

When client access the web page I have created I should be able to access/read the client hard disk.

Let me know,

Any ideas would def help me.

Thanks,

Sreenath

Re: Reading local file on the client side

leppie17-Jan-05 4:40

leppie

17-Jan-05 4:40

That is disabled by default for security. Look in the .NET control panel to adjust the security of the assembly.

^{top secret
Download xacc-ide 0.0.3 now!
See some screenshots}

Re: Reading local file on the client side

Heath Stewart17-Jan-05 7:02