C# Discussion Boards - CodeProject

network path in conjunction with file.exists

17-Jan-05 6:18

There's many ways, and some of which are included in VS.NET. There's the Object Browser which you can access from the View menu, as well as the Class View similar to the original Class View for VC++ (and works the same as VC++, which several enhancements). If you want to see the IL for a module or modules within your assembly, you can open your assembly in ildasm.exe that ships with the .NET Framework SDK, which is installed by default with VS.NET (under the program folder for VS.NET typically called FrameworkSDK).

There's also third-party controls like .NET Reflector[^] that can disassemble and decompile managed code, as well as generate callee graphs.

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]

Re: C# class hierarchy

17-Jan-05 11:55

Thanks for your suggestion, but I dont believe the Object Browser and Class View even do 10% of what I want.

In VS6, I could very quickly see which classes are derived from any other class (current project/BSC-file only of course). This particular feature is very useful when trying to grasp the complexity of a new software library for example. I got some 20K lines of undocumented code in my lap today and this feature alone would cut days from the time needed to learn the existing code.

Agreed, the BSC files had drawbacks, only beeing updated when compiling, could only use one at a time etc, but I still believe it was a better technology than the current.

Class View and Object Browser seems to me be doing the same thing, at least regarding my own code, and that is to show the base classes and the members, and that is all and well in itself, but not nearly enough.

HOWEVER, now that I am done complaining and have stated that things were better in the goold ol' days, I must say that the .NET Reflector does what I need. Its a little cumbersome to use, but I can live with that.

Thanks alot for pointing out this great tool for me!

(Now maybe you could suggest a good tool that draws class hierarchies too? Laugh | :laugh:

)

************************
Peter Andersson

RB@Emphasys17-Jan-05 5:38

RB@Emphasys

17-Jan-05 5:38

Hello All,

Quick question, i dont seem to beable to get the file.exists to work with a file that sits on a networked path. Ive triple checked the path. Now I am running this from an asp.net webservice, would I need to set up security for the asp.net user in the folder where the file exists on the network to get this to work properly?

Thanks!
Ryan

Re: network path in conjunction with file.exists

Heath Stewart17-Jan-05 6:28

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