Search Results

Search found 31 results on 2 pages for 'will marcouiller'.

Page 2/2 | < Previous Page | 1 2 

  • Getting the constructor of an Interface Type through reflection?

    - by Will Marcouiller
    I have written a generic type: IDirectorySource<T> where T : IDirectoryEntry, which I'm using to manage Active Directory entries through my interfaces objects: IGroup, IOrganizationalUnit, IUser. So that I can write the following: IDirectorySource<IGroup> groups = new DirectorySource<IGroup>(); // Where IGroup implements `IDirectoryEntry`, of course.` foreach (IGroup g in groups.ToList()) { listView1.Items.Add(g.Name).SubItems.Add(g.Description); } From the IDirectorySource<T>.ToList() methods, I use reflection to find out the appropriate constructor for the type parameter T. However, since T is given an interface type, it cannot find any constructor at all! Of course, I have an internal class Group : IGroup which implements the IGroup interface. No matter how hard I have tried, I can't figure out how to get the constructor out of my interface through my implementing class. [DirectorySchemaAttribute("group")] public interface IGroup { } internal class Group : IGroup { internal Group(DirectoryEntry entry) { NativeEntry = entry; Domain = NativeEntry.Path; } // Implementing IGroup interface... } Within the ToList() method of my IDirectorySource<T> interface implementation, I look for the constructor of T as follows: internal class DirectorySource<T> : IDirectorySource<T> { // Implementing properties... // Methods implementations... public IList<T> ToList() { Type t = typeof(T) // Let's assume we're always working with the IGroup interface as T here to keep it simple. // So, my `DirectorySchema` property is already set to "group". // My `DirectorySearcher` is already instantiated here, as I do it within the DirectorySource<T> constructor. Searcher.Filter = string.Format("(&(objectClass={0}))", DirectorySchema) ConstructorInfo ctor = null; ParameterInfo[] params = null; // This is where I get stuck for now... Please see the helper method. GetConstructor(out ctor, out params, new Type() { DirectoryEntry }); SearchResultCollection results = null; try { results = Searcher.FindAll(); } catch (DirectoryServicesCOMException ex) { // Handling exception here... } foreach (SearchResult entry in results) entities.Add(ctor.Invoke(new object() { entry.GetDirectoryEntry() })); return entities; } } private void GetConstructor(out ConstructorInfo constructor, out ParameterInfo[] parameters, Type paramsTypes) { Type t = typeof(T); ConstructorInfo[] ctors = t.GetConstructors(BindingFlags.CreateInstance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.InvokeMethod); bool found = true; foreach (ContructorInfo c in ctors) { parameters = c.GetParameters(); if (parameters.GetLength(0) == paramsTypes.GetLength(0)) { for (int index = 0; index < parameters.GetLength(0); ++index) { if (!(parameters[index].GetType() is paramsTypes[index].GetType())) found = false; } if (found) { constructor = c; return; } } } // Processing constructor not found message here... } My problem is that T will always be an interface, so it never finds a constructor. Might somebody guide me to the right path to follow in this situation?

    Read the article

  • How to Implement an Interface that Requires Duplicate Member Names in C#?

    - by Will Marcouiller
    I often have to implement some interfaces such as IEnumerable<T> in my code. Each time, when implementing automatically, I encounter the following: public IEnumerator<T> GetEnumerator() { // Code here... } public IEnumerator GetEnumerator1() { // Code here... } Though I have to implement both GetEnumerator() methods, they impossibly can have the same name, even if we understand that they do the same, somehow. The compiler can't treat them as one being the overload of the other, because only the return type differs. When doing so, I manage to set the GetEnumerator1() accessor to private. This way, the compiler doesn't complaint about not implementing the interface member, and I simply throw a NotImplementedException within the methods body. However, I wonder whether it is a good practice, or if I shall proceed differently, as perhaps a method alias or something like so. What is the best approach while implementing an interface such as IEnumerable<T> that requires the implementation of two different methods with the same name?

    Read the article

  • How to avoid the Windows (XP) Security Warning when launching a "DOS" command line within C#?

    - by Will Marcouiller
    This question is related to this initial question asked a little while ago. Now, that I have chosen the extracting tool, I'm iterating through a given in command line parameter directory and subdirectories to extract the compressed .zip files. private static void ExtractAll(DirectoryInfo _workingFolder) { if(_workingFolder == null) { Console.WriteLine("Répertoire inexistant."); return; } foreach (DirectoryInfo subFolder in _workingFolder.GetDirectories("*", SearchOption.AllDirectories)) foreach(FileInfo zippedFile in subFolder.GetFiles("*.zip", SearchOption.AllDirectories)) { if(zippedFile.Exists) { ProcessStartInfo task = new ProcessStartInfo(@".\Tools\7za.exe", string.Format("x {0}", zippedFile.FullName)); Process.Start(task); } } } But everytime I start a 7za process, the Windows Security Warning prompts. I would like to avoid such annoying behaviour, so here's my question: How to avoid the Windows (XP) Security Warning when launching a "DOS" command line within C#?

    Read the article

  • What is a practical usage of Code Contracts in .NET 4.0?

    - by Will Marcouiller
    In order to fully understand and take advantage of the new features and enhancements provided with the coming of the new .NET Framework 4.0, I would like to get an example of real-world application of the Code Contracts. Anyone has a good example of application of this feature? I would like to get a code sample with a brief explanation to help me get up and running with it. Thanks! =)

    Read the article

  • C# InternalsVisibleTo() attribute for VBNET 2.0 while testing?

    - by Will Marcouiller
    I'm building an Active Directory wrapper in VBNET 2.0 (can't use later .NET) in which I have the following: IUtilisateur IGroupe IUniteOrganisation These interfaces are implemented in internal classes (Friend in VBNET), so that I want to implement a façade in order to instiate each of the interfaces with their internal classes. This will allow the architecture a better flexibility, etc. Now, I want to test these classes (Utilisateur, Groupe, UniteOrganisation) in a different project within the same solution. However, these classes are internal. I would like to be able to instantiate them without going through my façade, but only for these tests, nothing more. Here's a piece of code to illustrate it: public static class DirectoryFacade { public static IGroupe CreerGroupe() { return new Groupe(); } } // Then in code, I would write something alike: public partial class MainForm : Form { public MainForm() { IGroupe g = DirectoryFacade.CreerGroupe(); // Doing stuff with instance here... } } // My sample interface: public interface IGroupe { string Domaine { get; set; } IList<IUtilisateur> Membres { get; } } internal class Groupe : IGroupe { private IList<IUtilisateur> _membres; internal Groupe() { _membres = new List<IUtilisateur>(); } public string Domaine { get; set; } public IList<IUtilisateur> Membres { get { return _membres; } } } I heard of InternalsVisibleTo() attribute, recently. I was wondering whether it is available in VBNET 2.0/VS2005 so that I could access the assmebly's internal classes for my tests? Otherwise, how could I achieve this?

    Read the article

< Previous Page | 1 2