|
thanks a lot sathish.
I am through.I did a mistake in DirectorySearcher.
|
|
|
|
|
This should work for you. You need to specifiy the domain controller server name including its domain name in full. The following code should make things alot clearer.
DirectoryEntry de= new DirectoryEntry();
de.Path = "LDAP://clown.acme.com"; //clown is the server name hosting the domain controller & acme.com is the domain name.
de.Username = "administrator";
de.Password = "passw$rd";
de.AuthenticationType = AuthenticationTypes.Secure
//now lets search for a user using the above credentials
try
{
DirectorySearcher searcher = new DirectorySearcher();
searcher .SearchRoot = de;
searcher .Filter = "(cn=" + "Domin Admins" + ")";
SearchResultCollection results = searcher .FindAll();
Console.Writeline(results.Count.ToString())
}
catch (Exception exception)
{
Console.Writeline(exception.Message);
}
|
|
|
|
|
I saw an interesting point raised here: http://www.atrevido.net/blog/2007/08/02/C+Frustration.aspx[^]
The C# 3 spec does not permit assigning a labmda expression to type infered value. So the following statement is invalid:
var Add = (int a, int b) => a + b;
The keyword var will give error CS0815, "Cannot assign 'lambda expression' to an implicitly typed local".
If the type is changed from var to Func<int, int, int>, the error goes away. The type of this lambda expression is not ambiguous, so the error must simply be a limitation in the type inference. Does anyone know if Microsoft has plans to fix this issue? If the type is known and expressible as a variable, then I see no good reason why this variable should behave differently than any other type-infered generic variable.
I ran into this problem while using VS2008 beta 1, so if it works in beta 2, please let me know.
-sharoz
|
|
|
|
|
Have you looked to see if this isssue has been raised on http://connect.microsoft.com[^]?
Thats were bugs and suggestions are reported back to MS and where they give answers to those bugs and suggestions.
If theres nothing there already about this you might want to submit some feedback and they *might* change it. If theres already feedback about it then you can show your support for it ... the more support for an issue, the more likely they are to do something about it.
|
|
|
|
|
|
And they've already replied 
Thanks for your feedback. We have reproduced this bug on Vista and OrcasBeta2VSTS, and we are sending this bug to the appropriate group within the Visual Studio Product Team for triage and resolution. Thank you, Visual Studio Product Team.
Posted by Microsoft on 20/08/2007 at 02:24
of course this doesn't mean they'll defiantly do something about it ... but atleast they are looking at it
|
|
|
|
|
Hi all!
I have Windows Services and a WPF application that should share a common resource (config file).
To make sure that no application is reading while another is writing I'm locking this resource with a system-wide Mutex.
It doesn't work. The Mutex doesn't seem to be unique.
Can it be that a Mutex is not unique if a Windows Service (running under the System account) and an WPF application (running under the user account) try to create a Mutex?
thanks,
MMartin
|
|
|
|
|
You need to use a named mutex for it to be system wide.
---
single minded; short sighted; long gone;
|
|
|
|
|
Thanks, but "I'm locking this resource with a system-wide Mutex" (=named Mutex)
MMartin
|
|
|
|
|
Ok, I'm not certain as to why you would be doing it that way.
Have you checked the error codes or exception codes that are being generated?
Is your security descriptor set up properly?
Phil
|
|
|
|
|
Hi,
we found out that the Windows Services created a Mutex named:
\BaseNamedObjects\Map_ConfigFile_Mutex
while the WPF-Application (Admin = Icon in System Tray with hidden Window) creates:
\Sessions\1\BaseNamedObjects\Map_ConfigFile_Mutex
Any idea how I can solve this issue?
Thanks,
MMartin
|
|
|
|
|
Problem solved:
"[...] The \Sessions\1\... is created by Terminal service session (or Fast User Switching which uses terminal services). To make a Mutex global across all sessions prefix the name with 'Global\' [...]"
MMartin
|
|
|
|
|
Hi,
A Multiline textbox contains these strings
"Line1
Line2
Line3"
Is there any builtin function to extract text on the basis of line terminator or i need to write my own function to parse it.
Best Regards,
Mushq
Mushtaque Ahmed Nizamani
Software Engineer
Ultimus Pakistan
|
|
|
|
|
Have a look at Textbox.Lines property.
|
|
|
|
|
you can use textbox1.Text.Split function to split the string based on a particular character.
Rocky
You can't climb up a ladder with your hands in your pockets.
|
|
|
|
|
Thanks
Best Regards,
Mushq
Mushtaque Ahmed Nizamani
Software Engineer
Ultimus Pakistan
|
|
|
|
|
Hi all,
How does one debug COM dlls? I'm reasonably new to the software application game and as such have not have had much experience with using dlls (COM or otherwise); previously I've been able to debug non-COM dlls by simply enabling 'Debug unmanaged code' in the VS2005 project setttings with no problems. Obviously, I need to make sure that I also have the dll's pdb file in the same folder as the dll. At this stage it's probably wise to point out that my (rather limited) idea of a non-COM dll is one that does not need a separate interop dll; the interface is written into the .NET project.
My limited understanding of interop and dlls has carried me this far; but today I've encountered the need to debug a COM dll (one that does not reside in the same directory as my executable; instead there is an interop dll which presumably handles the communication between the .NET app with the dll). All my previous experience with debugging dlls (above) has not helped a jot, I'm thinking that there's a separate process to have to get through because of the interop dll.
Can anyone help?
cheers!
|
|
|
|
|
Hi can you give me more details regarding the com object .
1.is it registered under thr com+ or with regsvr32 command ??
2.do you have the com dll sources ??
thanks
|
|
|
|
|
Hi,
1. It is registered using regsvr32
2. Yep, I have access to the source code. I'm assuming that helps?
Thanks
|
|
|
|
|
ok
your com dll will be hosted by any process using it, in this case your application.
try the following steps:
1.open the com object source code
2.set break points
3.attach the debuger to your application using (managed and native option in the attach to box).
4.call the com object from your application.
thanks
|
|
|
|
|
I'm sorry, I didn't mention that the COM object is developed using VC 6.0. That (probably) means that it has no concept of managed or native code. I did try this before but it did not work - VC 6.0 did not allow me to set break points when I attach the debugger to a running application.
Any more ideas?
|
|
|
|
|
are you trying to debug the com under vc6.0 ????
|
|
|
|
|
Here's the deal: my main app is developed on VC2005 while the COM dll is developed on VC6.0. I don't care which IDE I use to debug the COM but obviously if I were to want to open up the COM's source code and do a attach to process debug session, it's going to have to be through VC6.0. Correct?
|
|
|
|
|
ok
1.open the com project under vc6.o IDE
2.under the com project settings in the debug tab enter your application executable
3.start the debugger (this will start your application)
when your application will call the com object it will stop at the break point.
this is the way i used to debug com under vc6.0
|
|
|
|
|
That worked for me! Thanks for that
Out of interest, what recourse would I have if I didn't have access to the source code (but do have access to the pdb, debug dlls etc)?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
