I've got a problem with using Forest.GetCurrentForest() method when communicating with a Read-only domain controller.
The exception thrown is:
System.DirectoryServices.ActiveDirectory.ActiveDirectoryServerDownException: The server is not operational.
Note: Everything works fine when communicating with a RWDC.
Previously, to fix other issues when communicating with a RODC, we had to modify the way we created DirectoryEntry objects, making use of the AuthenticationType.ReadOnlyServer flag. However I've seen (using reflector) that the GetCurrentForest() method creates its own DirectoryEntry object using a Utils class, which in turn uses a DefaultAuthType.
So, my question is: Does anyone know how to set/modify the DefaultAuthType so that it can return the required authentication type? Is there a better way to do this? The aim of this piece of code is simply to get the list of available domains visible to the server.
Thanks,
Ben
Well, doesn't seem like there's an easy answer to this. In the end we rewrote the code to not use the Domain/Forest objects...
What I do to "overcome" this issue was, I first try to get the Forest.GetCurrentForest(), and if exception thrown, I then use Domain.GetComputerDomain() for last solution, of cause, the list now only contain the domain that the web server joined.
Related
I have a problem, which I realy can't get behind.
I have two programms, the communicate throu IPC using BinaryFormatting. I placed the client- and server-class in the same assembly including all classes to transport data.
What I don't understand is why I'm getting a serialization exception with "Assembly not found" when I'm trying to recive an object but sending one works perfect.
So if the IPC client calls a method "Config GetConfig()" that returns my config-class the exception is thrown. When I call a mehtod "SetConfig(Config config)" the config arrives at the IPC-server without any problem.
I've already tried to switch to SoapFormatter instead of Binary and tried working with interface instead of the class. All with the same result. Sending data works fine, getting Data throws the desirialization exception.
Can somebody give me a hint, how I can fix this issue? Or at least what to look for to fix it?
so some time after asking the question I finally found the problem and the solution.
Problem was, that my client is part of a COM-Component and a post directed me the way, that the binaryformatter doesnt care about already loaded assemblies. It looks like it always tries to resolve the assembly from the AppDomain.CurrentDomain.BaseDirectory which is the path of the executable in my case it's outlook.
So the solution was to bind to the AssemblyResolve-Event in the appdomain an resolve the assembly from the correct directory.
Hope this helps if somebody else has the same problems.
As logmeinrescue doesn't support batch users creation using a simple csv upload or similar and instead offers the ability to create user accounts using http post and get or by using soap I thought I would look into this.
Unfortunately following the code example in this link I have been unable to work out how to utilize the SOAP aspect of the code as I have never had previous experience using it.
So far I have written a fairly basic program that reads in the csv with all the user account data needed for creation and would loop through and assign the values needed.
If anyone could assist it would be greatly appreciated, I have tried to look up some documentation in regards to c# and soap but I was unable to find something that really helped me with configuring for logmein.
The c# example at the bottom of documentation you link to looks helpful but flawed. APISoapClient does not have a CookieContainer property so I would try it without the line of code that tries to set it. Later in the code there is a call to sAPI.createUsers but the example has not defined sAPI, I think they meant to re-use proxy.
To get started the easy way, right-click your project References and select Add Service Reference. Enter their endpoint and click GO:
https://secure.logmeinrescue.com/api/API.asmx
If you change the namespace from Service1 to match the example (APIServiceReference) your code will look like the example. From then on you can perform API operations basically just like you were dealing with classes, the SOAP mess is abstracted away for you.
I have this project, which consists of a WCF Library acting as a Server for a Trouble Ticket system.
Link for solution skeleton: http://imgur.com/eZqe5Q8
I have an interface that allows me to access the server methods.
I have a DB as you can see in the picture, called "MainDB".
I have a website with a service reference to the server which works perfectly fine.
Then I needed to create a GUI application client that accesses the same server interface. I did this by creating a WPF application. I reference the server, just the same as I did in the website and use the same interface, and I call the exact same method, in this case the Login method, which you can check in this image: http://imgur.com/3PajH3U
But when I call this method from the WPF I get an exception on the red squared line which says this:
"An unhandled exception of type 'System.NullReferenceException' occurred in TTService.dll
Additional information: Object reference not set to an instance of an object."
I thought it might be because of the DB not being "published", but it was. I run the website and the WPF at the same time and one runs perfectly smooth while the other causes that exception. I can't get what's causing this, probably because I'm still not experienced in this technology.
The fact that the origin of the method call is different doesn't seem to me like a plausible cause because I can't understand how the method would know where the call originated.
I'm sorry I can't put the images in the post but not enough reputation yet.
Thank you for any help.
I fixed this. It actually was the Interface implementation that was wrong. Sorry for the misinformation.
Up until recently we used custom exceptions with an inbuilt errorcode to allow us to communicate errors or problems we don't like around our systems.
However, I was shown a different method where you have a publicly exposed collection of errors on each class that you populate if there was a problem. The calling method then calls myObject.IsValid (which sees if the error collection has any entries) to check if the call was successful. If it wasn't then you can iterate through the error collection to see what went wrong. As far as I understand this is how MVC works with the ModelState.
The claim was this was the more efficient approach to error communication as there is an overhead to throwing exceptions.
Is this claim true? Is there a third option that is even better than the above? What is the correct way to communicate errors and problems around a .NET application?
I am using db4o in two seperate projects that share the same classes but not the same .dll . I am fixing this so that they share the same .dll but I need to rename the classes. According to the documentation you set up configuration and open the db with the renames and it updates everything. I have tried this but when I try to open the DB the project just hangs. Am I missing something here
config.Common.ObjectClass("DllName.Old, DllName")
.Rename("NewDll.New, NewDll");
var db = Db4oEmbedded.OpenFile(config, DBFile);
That looks correct to me and should work. It really should work when the class-names and assembly names are correct. The class is not a generic class, right?
You don't get any exception, right? Is db4o just hanging or actually doing some work?
Edit: I could reproduce a stack-overflow exception with renaming a class. Maybe you are running into a stack overflow exception as well, but you cancel it before it actually happens?
Anyway, I created a bug-entry in the db4o-bugtracker.
I was successful with the following answer:
https://stackoverflow.com/a/1138178/541420
Very buggy otherwise though :(