Develop Reference

iOS iCloud failing to write with, Couldn't get container configuration from the server error

I have one app that I wrote already reading from and writing to the iCloud. I am essentially using the same code in my new app to do the same thing, but for some reason it will not work, giving me the following error, "Couldn't get container configuration from the server". Let me clarify, with this new app it does puts an entry in iCloud under manage storage, but instead of being under the name of my app, it is under adhoc.
Here is the line in my info.Plist,
Here is the line from my Entitlements,plist
lastly, here is my identifier defined on the apple developer site,
I have verified and reverified that everything is pointing to the correct thing so I am baffled. Any help would be much appreciated.
EDIT I guess what it is doing is writing file to my phone, but when it goes to save data to it, it fails with this message, Here is my call to save the data.
CKRecordID recordID = new CKRecordID(strDate);
await Task.Delay(200);
// Save it to iCloud
await pvc.SaveToiCloud(newRecord);
Here is my code to save the record,
public async Task SaveToiCloud(CKRecord newRecord)
{
ThisApp.PrivateDatabase.SaveRecord(newRecord, (record, err) =>
{
Edit:
I was thinking that possibly the number of nodes I had was too many, so I took out the "dist" one you see below, but that did not help. I thought maybe that was why I was seeing module name of adhoc under icloud on my phone, but I guess I was wrong.
Old:
New:
Edit
I have been doing more digging and found that this line of code is actually the one throwing the error.
File.WriteAllText(Path.Combine(filePath.Path, name + date), "Test");
The name and date contain correct values and the path looks fine to me... I guess... Don't know actually how it should look. Here is how the file path is getting set right above this call,
NSUrl filePath = NSFileManager.DefaultManager.GetUrlForUbiquityContainer(null).Append("Documents", true);
If anyone could offer any advice, I would be most appreciative.

So, I finally figured out the issue and it works like a champ now. The issue was the case in my bundle id in my info.plist. In CloudKit the DB name was all lower case, but my bundle Id in my info.plist, had AdHoc as my last node instead of adhoc as was in the CloudKit. You might say, what does the bundle Id have to do with the iCloud name, and actually I am not really sure, but I noticed that it was taking the case of that last node from my Bundle Id, not the case specified in the iCloud definition as I have shown above. Hope this helps someone who is struggling with a similar issue Have a great day!

Check if ASP.NET WebForms page exists based upon relative URL provided in Query String

Given a query string url of the form "~/folder/page.aspx", is there a way to check if that page exists within the scope of the application?
I'm in a situation where I'm fixing a minor bug where, if a user attempts to log in to the application from a set of publicly accessible application error pages, then they're redirected back to that public error page. I've been asked to have the user be redirected to the main home page if they're logging in to the application from this state.
So far I've fixed the issue by hard coding the paths to the affected pages in a switch statement, checking the querystring against the hardcoded paths. I feel this is hacky and bad, and would love a more dynamic solution, but I can't seem to find one.
Any help would be greatly appreciated.
Edit - Specifically, my preferred solution would simply be to check that the path defined by the query string url (without a priori knowledge of the exact format) leads to a specified folder within the scope of the application.

So, after looking some more, I discovered Server.MapPath. I can use this in conjunction with System.IO.Directory to see if the file is contained within the directory.
string targetUrl = Request.QueryString["redirect"];
string serverUrlPath = Server.MapPath(targetUrl);
string serverDirPath = Server.MapPath("~/ErrorPages");
foreach (string file in Directory.EnumerateFiles(serverDirPath))
{
if (file.Equals(serverUrlPath, StringComparison.OrdinalIgnoreCase))
{
Response.Redirect(Master.ProjectSearchRedirect());
}
}
Response.Redirect(targetUrl);
I was hoping for something a little more refined (even just a Directory.Contains kind of encapsulation).

Active Directory custom attribute can not be seen by it's owner on some computers

A added a custom attribute to the Active Directory Schema. On one machine when I try to query the attribute I get errors back from my code.
Here is the C# version to test this out.
static class Program
{
static void Main()
{
Console.ReadLine();
DirectoryEntry directoryEntry = (DirectoryEntry)UserPrincipal.Current.GetUnderlyingObject();
//Execption on this line
var allowedDatabases = directoryEntry.Properties["vwDBAccess"];
foreach (var record in allowedDatabases.OfType<String>())
{
Console.WriteLine(record);
}
Console.ReadLine();
}
}
System.Runtime.InteropServices.COMException was unhandled
Message=Unknown error (0x8000500c)
Source=System.DirectoryServices
ErrorCode=-2147463156
StackTrace:
at System.DirectoryServices.PropertyValueCollection.PopulateList()
at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
at Sandbox_Console.Program.Main() in C:\Users\srchamberlain.VW\documents\visual studio 2010\Projects\Sandbox Console\Sandbox Console\Program.cs:line 16
InnerException:
The Error Code 0x8000500c represents E_ADS_CANT_CONVERT_DATATYPE. This only happens on one machine. I have 3 other computers (all part of the same domain as the first computer) and those behave correctly when running the exact same code for the exact same user and give the the content of the attribute. Also if I run as a different user, on the same box, but query the bad user's attributes I can pull up the information correctly when connecting as another user.
I have tried refreshing the schema on the box using the technique from this KB article but the issue is still happening.
What is going wrong on this one computer?
Clarification:
vwDBAccess is a multivalued string, so when it works directoryEntry.Properties["vwDBAccess"] return a string with there is one item, sting[] when there is more than one, and null when there are no items. This account has 3 items set. When I run as a different user and query the bad user I correctly get string[3] returned.

Typically if something is only happening on one machine in a network then it boils down to service pack and update levels of the OS or interaction with other software on the system (A/V is the worst offender).
The first thing I would do is look at the SP and updates applied to the working machines, then compare that to the non-working one. You should see one of two situations:
If the working machines are more up to date, then apply whatever updates are necessary to the non-working machine.
If the working machines are less up to date, then update one and see if it starts failing. If that's the case, you might need to contact MS.
My gut says that the non-working machine is simply out of date.

Querying custom LDAP property via System.DirectoryServices in C#?

I have a custom LDAP schema installed on my OpenLDAP server which is as follows:
attributeType ( 999.0.01
NAME 'picturePath'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
objectClass ( 999.1.01
NAME 'indieStackTeam'
DESC 'Team definition for IndieStack'
SUP groupOfUniqueNames
STRUCTURAL
MAY ( picturePath )
)
In my ASP.NET MVC 2 application, I'm querying for the picturePath property like so (and it is confirmed that picturePath exists in the list of keys):
this.Picture = properties["picturePath"].Value as string;
When I attempt to do this under .NET 3.5 I get the following exception:
[COMException (0x8000500c): Unknown error (0x8000500c)]
System.DirectoryServices.PropertyValueCollection.PopulateList() +347013
System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName) +49
System.DirectoryServices.PropertyCollection.get_Item(String propertyName) +150
However, when the same code runs under Mono (on the same server as OpenLDAP) it works perfectly fine. Clients such as LDAPAdmin can also read the picturePath property correctly.
More so, it's only when I go to read the value that it fails; I can see the property is there in the keys list, I just can't access it.
Unfortunately unknown error doesn't tell me a lot about what's going wrong, but I'm finding the .NET implementation of System.DirectoryServices is very flaky (you get the same unknown error if you connect to the LDAP server using lowercase in 'DC=').
Has anyone had this problem before and if so, how is it solved?

Two things you should check:
1) does that particular user object indeed have a value in picturePath? You might want to check for existance of the property before accessing it:
if(properties.Contains("picturePath") && properties["picturePath"].Count > 0)
{
....
}
2) If I remember correctly, to get access to custom attributes, you should explicitly refresh the cache for a user object before doing anything:
DirectoryEntry de = ......; // find / assign that DirectoryEntry somehow
de.RefreshCache(); // to load all properties from the directory
or:
de.RefreshCache(new string[] { "picturePath" }); // to just load the "picturePath" attribute
Also: the classes in System.DirectoryServices are really mostly geared towards being used against Active Directory - there might be "surprises" or subtle incompatibilities when used against some other LDAP server - like OpenLDAP.

It seems that the .NET LDAP client expects a correctly formed OID for attribute types and object classes.
You'll note that I was using OIDs of the form 999.X.YY, which while they might be syntactically correct, aren't usually encountered in the real world. My guess is the LDAP client parses OIDs and since these don't conform to what is expected, it throws an error.
I changed the OIDs to 1.3.6.1.4.1.40000.1.3.1 and 1.3.6.1.4.1.40000.1.4.1 respectively (I've also applied for a PEN, which will give me an assigned number instead of '40000'), refreshed the schema in the server and recreated the entries and the LDAP client now correctly reads the custom attributes.

Strange COM interop exception 0x80005000 using System.DirectoryServices.AccountManagement libraries

I'm trying to write something that (amongst other things) adds a user to an AD group - using VS2010, .Net4 and the library facilities in System.DirectoryServices.AccountManagement.
I've gotten a user and group by code like the sample below, and this works for other operations like enabling or disabling accounts.
group = System.DirectoryServices.AccountManagement.GroupPrincipal.FindByIdentity(_UserContext, Name);
user = System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(_UserContext, Name);
Now, trying to add the user to the group like:
group.Members.Add(user);
I get an error with a stack trace beginning like the one listed below with a COM interop error 0x80005000 (unknown). This also happens with other users and on 32 and 64 bit builds. Searching this on the web comes up with a few forum questions, but I can't find any answers. In theory, this should work - this codeproject sample is doing much the same thing.
Has anyone seen this error or have any idea what might have caused it?
Stack trace top:
Unhandled Exception: System.DirectoryServices.AccountManagement.PrincipalOperati
onException: Unknown error (0x80005000) ---> System.Runtime.InteropServices.COME
xception: Unknown error (0x80005000)
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_AdsObject()
at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne
)
at System.DirectoryServices.DirectorySearcher.FindOne()
at System.DirectoryServices.AccountManagement.ADStoreCtx.IsMemberOfInStore(Gr
oupPrincipal g, Principal p)
--- End of inner exception stack trace ---
at System.DirectoryServices.AccountManagement.ADStoreCtx.IsMemberOfInStore(Gr
oupPrincipal g, Principal p)
at System.DirectoryServices.AccountManagement.PrincipalCollection.ContainsNat
iveTest(Principal principal)
at System.DirectoryServices.AccountManagement.PrincipalCollection.Contains(Pr
incipal principal)
at System.DirectoryServices.AccountManagement.PrincipalCollection.Add(Princip
al principal)
at System.DirectoryServices.AccountManagement.PrincipalCollection.Add(UserPri
ncipal user)

I also ran into the same issue with a (GroupPrincipal instance).Members.Add(UserPrincipal instance).
The workaround (in IronPython) is rather simple thanks to the GetUnderlyingObject method.
de = group.GetUnderlyingObject
# Group member DNs are kept in 'member' attribute in LDAP
de.Properties['member'].Add(user.DistinguishedName)
de.CommitChanges() # Save your work

Just ran into this and noticed that the code project sample was explicitly using the domain's name when creating the context (instead of using null). I changed my code to explicitly specify the domain name, and now it's working fine - I can group.Members.Add(user) without issue.