Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


aza aza
  • How do I contact Intel regarding a product suggestion?

    Shining Arcanine wrote:
    Considering Microsoft and Intel are partners, I thought it would be a good idea to ask here as I have no idea how to contact who ever makes the decisions regarding what products Intel develops/produces/sells. Anyway, does anyone know how to get in touch with Intel regarding a product request/suggestion?
    If it's not confidential you could post it up to this messgae board and it will be passed along. If it is confidential then I have no idea of the approach to take, you need non-disclosures, patents etc. etc.

    There is an internal web site within Intel that allows "innovation" suggestions to be put forward. The suggestions are processed by managers in the IT Innovation deparment.


  • GotDotNet vs SourceForge


    I saw a question posted on the GloblBank wiki about why developer's aren't participatng on the GotDotNet message boards.

    I don't claim to know the answer for all developers but personally I participate in SourceForge instead of GotDotNet. And indeed there are a large number of .Net based projects in SourceForge so perhaps I am not the only one.

    The reasons I use for SourceForge instead of GotDotNet:

    1. In SourceForge I can always read the code. GotDotNet I may or may not be able to. This has nothing to do with any philosophy towards open source it's just that as a developer it's often what I am interested in as oppossed to just getting some binaries.

    2. There is a lot more activity in SouceForge. This is a chicken-and-egg argument.

    3. GotDotNet seems in some ways like a Visual Source Safe for the Internet. My team uses VSS to store our code. While I would feel comfortable hosting our code in SourceForge (if it was open-source) I wouldn't feel so comfortable about GotDotNet. This is mainly due to the maturity, support arrangements and access controls in the GotDotNet system. As it becomes more stable perhaps this will change.


  • Lack of Managed ​Authenticat​ion

    Seems like Intel is assuming it's full steam ahead with LaGrande and Longhorn.


    An interesting point in the article is the mention of the need for the NGSCB software to run alongside the OS and mediate access for application to secure hardware functions. So computers will now have two OS'? Or even three with the BIOS' getting more and more advanced. Sigh.. it's just as well WinFX is going to abstract away all this complexity for us poor application developers.

    By the way does anybody know any of those memory drugs I am pretty sure my head is nearly full but there's still Yukon, Longhorn etc. etc. to go.


    P.S. Please excuse me for conversing with myself.

  • Configurati​on Files

    Rafa® wrote:
    I don't even know if it's useful for something, but I was wondering...
    Because, I was developing with unit testing, and I was searching a way to the testing assembly gets the ConnectionString from the Configuration file (it's still unsolved)... Then it comes up in my mind...
    If you are using NUnit you can specify the configuration file for the assembly being tested. In addition if you are also using Nant it's all wrapped up nicely in an XML file for you Smiley.


  • Lack of Managed ​Authenticat​ion

    Hi spod,

    Seeing as how you are going to be asking some questions in the platform security area...Wink

    Is there any update on the status of Palladium (aka Trusted Computing Platform, aka NGSCB, aka La Grande etc. etc.)? Is it still on the roadmap or have the rather ironic concerns of privacy advocates caused a rethink (I say ironic because the same advocates often desire a more secure platform and not because I consider privacy irrelevant)?

    One among many reasons I ask this is that from an application developer's perspective I see a big need for an application secure store. The user should always be able to remove the application, including the store, but an application often needs to have a security layer that is not dependent on the user.

    An example would be a peer-to-peer application. The application wants to expose services on participating peers but only to instances of the same or designated applications. Today the only security mechanisms available, on any PC platform (since it's a hardware problem), are user based.


  • Registry Access

    Don't the Microsoft.Win32.Registry and RegistryKey classes have everything you need? As far as I was aware you could open any key you liked, providing you had permissions, using these classes...

    Micorosft.Win32.Registry.Users corresponds to HKEY_USERS, I don't have a HKEY_LOCAL_USERS (WinXP).


  • Lack of Managed ​Authenticat​ion

    spod wrote:

    When u say "you can sign soap requests on behalf of the user" do you mean you would like the user to be automatically assoicated with a cert / private/public key pair  that can be used for digitally signing etc? Or are you just looking for a way to interface with the certificate api in managed code?

    Hi spod,

    Any samples coming before Longhorn perchance? Wink.

    In answer to your question no I am not really looking for more cryptographic hooks for signing, encryption etc., What's currently available in the .Net BCL is more than suficcient.

    What is missing, at least for me, is the key management piece. Obviously this is not something that can be provided by a library alone it also depends very heavily on the underlying platform. What I am talking about is hooks into the coupling of Active Directory and cryptographic mechanisms. 

    A simple example of what I was trying to articulate in my last post is:

    An application running on machine A signs a message on behalf of user A and then sends the message to an application running on machine B. The application on machine B is able to verify that the message came from user A using the platform's security services, i.e. Active Directory.  

    There are numerous more use cases especially around getting remote processes to use delegation and impersonation, particularly with regards to web services and remoting (IIS mechanisms are not always suitable).

    I do have the managed SSPI example that is available on msdn and this has temporarily filled my gaps in the past. But I look forward to having more managed access into the Window's security infrastructure.

    A positive side benefit is that my C++ got a workout trying to solve some of these problems Smiley.


  • Lack of Managed ​Authenticat​ion


    The two biggest holes I have encountered in the .Net libraries are probably NTFS file access and user authentication. I fully appreciate that shifting from a Win32 API to a new API (in this case .Net) is a "huge" task and hopefully these two aspects are coming...

    In the meantime I have a question about what would be a good way to handle non-repudiability in an Active Directory environment.

    The System.Security.Principal.WindowsIdentity class lets me know the authenticated user is and the System.Net.NetworkCredential class even lets me make use of the authenticated user's credentials when using IIS. But what if the application needs to digitally sign a SOAP request or do some other cryptographic type operation on behalf of a user?

    I got a little bit excited with the release of WSE2 when I saw the multitude of classes and support available for digital signatures. However after playing around with it a bit I found that the classes to create security tokens from an XML signature, or similar, were all inaccessible and could only be used by way of an IIS SOAP extension, thus allowing only very narrow usage scenarios.

    I appreciate that using the Win32 API it is possible to serialise Windows security tokens but this is a task that would take weeks to month(s) rather then the day(s) that we, as .Net developers, are now expected to operate under.

    The ability to utilise single sign on and at the same time leverage distributed computing paradigms such as web services and remoting all require user authentication. Not having a managed API is a major, major disadvantage to being able to utilise one of the most basic services of a Windows environment!


  • Error Handling, use exceptions?

    amotif wrote:
    One should beware of falling into this as a default practice.  Every method should be considered closely for exceptions that it may generate or that callees may generate and the effect they have on the method's work and resources.  C# and VB.NET compilers don't have the Java compiler's ability to nag about exceptions you haven't explicity dealt with, so it's entirely up to you, the coder, to ensure that you won't be leaving resources in an untidy state.  Many methods won't need a try-catch block.  Some will.  Whether you want to discover the latter at 2am during a hands-off debug session on production boxes at go-live is somewhat up to how tidy you are about exception handling. Smiley
    Won't garbage collection take care of this?

    Sure if you are using an exotic resource, such as external calls into unmanaged code, then there would be a need to catch and clean up. However in the 99% of cases where you are just sticking to the base class libraries is this a concern at all seeing as no explicit disposal is required, exception or no?

    amotif wrote:
    Another aspect of bubbling up exceptions is that the meaning of an exception changes as it bubbles up the call stack. 


    The change in an exception's meaning tends to be particularly interesting as it crosses subsystem boundries.

    I agree with that point to an extent. I tend to use ApplicationException a fair bit to impart application specific error information back up the stack.

    When I first started utilising exception management I used to use try-catch blocks in every method. After a while this often seemed a bit pointless, for instance in cases where a file IO exception was caught and then subsequently rethrown half a dozen times up the call stack.

    Nowadays if there is not an exception condition that needs extra contextual information added (probably guilty here of verging on the lazy side of needs) then I dispense with the try-catch block altogether.

    The flip-side of catching and adding contextual info is that the real cause may then be hard to find. If an invalid argument caused the exception in the VerifyHash routine and it get's wrapped in an Unauthorised exception it could send the debugging developer way off on the wrong track. Theoretically if the original exception info is maintained with the wrapped one the developer could always obtain it but if it's a big call stack with lots of wraps it could become tiresome and easily be overlooked.


  • Interfaces

    clint_hill wrote:
    And so I would wonder how might there be a way to still get the advantages of interfaces yet keep the flexibility of classes. Abstract comes to mind and I was wondering how you guys play this into your designs?

    I use interfaces to:
    1. Provide an agreed upon signature for two or more developers,
    2. Provide a minimal clean access point for an implementation class.

    Classes are obviously where all the magic happens and serve a completely different purpose to interfaces. As far as abstract classes go if they only contain abstract members then they are equivalent to an interface anyway.

    I find I use interfaces more then base/abstract classes and polymorphism. While polymorphism is extremely powerful and useful the situations to which it is suited for don't appear that regularly.

    I don't see a class as being more flexible then an interface, they are used for different things. Unlike classes interfaces can't satisfy any functional requirements but if interfaces are used wisely they can provide the code with clearer and cleaner semantics; thus helping avoid smell and make life easier for maintainers. In more complex designs Interfaces also make it easier for multiple developers to build and subsequently use the software by providing unambiguos APIs.