Develop Reference

Confirm a Folder Exists on a Web Server from a C# Desktop Application

I am trying to confirm that a folder has been uploaded to my Website folder so that it can be accessed by a Desktop application. I keep getting an error that states that there is a URI format error on the connection string. There is no shortage of 'solutions' on the general internet but I cannot get anything to work, even ones on this site (of which I am a member for many years). Forward slashes, back slashes, no slashes ... on and on. I am thoroughly confused. The following seems to be a simple and correct code, but it does not work either even though it is a direct copy of a solution that was offered as correct! The passed string 's' is the name of the folder I am trying to look for. A polite simple answer, perhaps with an example, is my desperate request. Thank You.
private bool CheckFiles(string s)
{
bool exists = System.IO.Directory.Exists(#"\\\\http:/www.myserver.com/sites/"+ s);
return exists;
}

System.IO.Directory.Exists checks for a directory in the file system. The address that is provided as a parameter is a http-URL that is not supported by file system access.
If you want to check for the presence of the folder on a webserver, you need to use a http client to "talk" to the server. Send a GET or HEAD request to the URL. If this returns a 200 (ok), the folder exists, if it returns 404 (not found), it doesn't.
As you are using .NET Framework 4.5 (or 4.0), you can use WebClient or better HttpClient for this. The following should give you an idea of how to check for the folder:
using (var http = new HttpClient())
{
using (var req = new HttpWebRequest(HttpMethod.Head, "https://..."))
{
using (var resp = http.Send(req))
{
// This is a very broad condition;
// you can also check the StatusCode property against HttpStatusCode.NotFound
return resp.IsSuccessStatusCode;
}
}
}

Using Force.com for arbitrary REST API methods

NB: This is a duplicate of my question on https://github.com/developerforce/Force.com-Toolkit-for-NET/issues/357. I'll sync both threads after this is resolved.
I'm using the Force.com toolkit for .NET. SOQL queries are working fine for me, but I'm trying to also make a simple REST call similar to one I can make with the REST Explorer tool at https://workbench.developerforce.com/restExplorer.php.
My code is:
using (var queryClient = new ForceClient(authClient.InstanceUrl, authClient.AccessToken, authClient.ApiVersion))
{
// Works fine
string soql = GetMyQuery();
QueryResult<dynamic> result = await queryClient.QueryAsync<dynamic>(soql);
// Throws exception. Changing version # doesn't seem to have any effect.
dynamic restResult = await queryClient.ExecuteRestApiAsync<dynamic>("/services/data/v46.0/sobjects/Task/describe");
When I get to ExecuteRestApiAsync, I get the exception:
Salesforce.Common.ForceException
HResult=0x80131500
Message=Could not find a match for URL
Source=Salesforce.Common
StackTrace:
at Salesforce.Common.JsonHttpClient.<HttpGetAsync>d__4`1.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
[...]
I assume that my argument "/services/data/v46.0/sobjects/Task/describe", which works fine in the REST Explorer tool, needs to change. But I've guessed a bunch of different options (different versions, with or without leading URL string, etc.) and so far haven't gotten anything to work.
Can someone tell me how to use ForceClient to get the same results I get back from the Salesforce Workbench REST Explorer?

I ended up looking more closely at the ForceClient code. ExecuteRestApiAsync was not the correct call for this. For my specific example, there are 3 ways I found that work:
dynamic restResult = await queryClient.DescribeAsync<dynamic>("Task");
restResult = await queryClient.BasicInformationAsync<dynamic>("Task/describe/");
restResult = await queryClient.BasicInformationAsync<dynamic>("Task/describe");
(All 3 of the above lines return the same result)
This will work fine for sobjects. I don't think it's currently possible to use this library directly for things like reports which use "analytics" in their REST API definitions, but there are a couple workarounds that don't require recompiling the code. The cleanest and most performant of these that I've found is to pass your own HttpClient instances into the ForceClient ctor and use those directly instead of the methods on the ForceClient. An inspection of the ForceClient code will reveal that most of these methods are just thin string.Format() wrappers on HttpClient methods anyway.

Microsoft Dynamics CRM SDK CRMServiceClient connection string cache bug

Caching behavior of the last Dynamics SDK is driving me crazy.
First, if you want to use CrmServiceClient to access different environments you have to use the parameter RequireNewInstance=True; in the connection string. If not, every instance of CrmServiceClient will use the same connection, even if you create and dispose instances to different environments.
Now, even if you use the RequireNewInstance=True; in the connection string I found that cache still occurs in some scenarios.
var client1 = new CrmServiceClient("RequireNewInstance=True;
Url=https://myCompany.crm.dynamics.com;
Username=myUser#myCompany.onmicrosoft.com; Password=myPassowrd;
AuthType=Office365");
//Now, client 2 points to a url that doesn’t exists:
var client2 = new CrmServiceClient("RequireNewInstance=True;
Url=https://xxx.crm.dynamics.com; Username=myUser#myCompany.onmicrosoft.com;
Password=myPassowrd; AuthType=Office365");
The client2 keeps using the first connection string, so you cannot determine if the new connection string is correct.
Any ideas how to test Dynamics Crm connections strings correctly in my asp.net application?

Late reply, but the behavior you're seeing is because when you're specifying an erroneous URL the discovery service is used to ascertain which instance to connect to.
To prevent this specify SkipDiscovery=True in your connection string:
var connectionString2 = #"AuthType=Office365;Url=https://FAKE.crm.dynamics.com;Username=USERNAME;Password=PASSWORD;RequireNewInstance=True;SkipDiscovery=True;";
Edit: SkipDiscovery is true by default starting with 9.0.7, kudos to #mwardm

I think I found the problem. It seems to only happens on Dynamics 365 online trials, that was the reason we were getting inconsistent results depending on the environment.
Apparently, the url doesn't need to be completely valid to establish a connection to a CRM online trial environment, as long as the credentials are valid and the url structure is kept.
Let's consider the following example:
var client1 = new CrmServiceClient("RequireNewInstance=True;
Url=https://fake.crm.dynamics.com;
Username=myUser#myCompany.onmicrosoft.com; Password=myPassowrd;
AuthType=Office365");
In this case I can substitute the "fake" part of the url with whatever I want, but still execute requests correctly using the CrmServiceClient service.
If I try to do this with another environment (e.g. 2015, on premise, not-trial crm online, etc.), the IsReady property of the CrmServiceClient would return false and I would get an error in the LastCrmError property.
Very weird behavior, and difficult to pinpoint.
Now that I think I understand the inconsistent behavior I know that finally it will not affect our clients, so I will mark this response as the answer even if I still do not know why we have different behavior between a trial and a normal environment..

I agree choosing to reuse the existing connection if you don't include RequireNewInstance=true seems counter-intuitive, but I can't reproduce what you're seeing. If I try the following from LinqPad crmSvcClient2 will print out errors and then throw a null ref on the Execute call (8.2.0.2 version of the SDK). With this version of the SDK you'll want to always check LastCrmError after connecting to see if the connection failed.
var connectionString = #"AuthType=Office365;Url=https://REAL.crm.dynamics.com;Username=USERNAME;Password=PASSWORD;RequireNewInstance=True;";
var connectionString2 = #"AuthType=Office365;Url=https://FAKE.crm.dynamics.com;Username=USERNAME;Password=PASSWORD;RequireNewInstance=True;";
using (var crmSvcClient = new CrmServiceClient(connectionString))
{
"crmSvcClient".Dump();
crmSvcClient.LastCrmError.Dump();
((WhoAmIResponse)crmSvcClient.Execute(new WhoAmIRequest())).OrganizationId.Dump();
crmSvcClient.ConnectedOrgFriendlyName.Dump();
}
using (var crmSvcClient2 = new CrmServiceClient(connectionString2))
{
"crmSvcClient2".Dump();
crmSvcClient2.LastCrmError.Dump();
((WhoAmIResponse)crmSvcClient2.Execute(new WhoAmIRequest())).OrganizationId.Dump();
crmSvcClient2.ConnectedOrgFriendlyName.Dump();
}

Creating Facebook Event in C# Returns #100 Invalid Parameter

I'm trying to put together a small app that will allow me to create events in Facebook. I've already got my Facebook app set up and have successfully tested a post to my feed through the application using the code below.
wc.UploadString("https://graph.facebook.com/me/feed", "access_token=" + AccessToken + "&message=" + Message);
When I try to take things to the next step, I've just hit a brick wall.
The code that I've written is here:
JavaScriptSerializer ser = new JavaScriptSerializer();
wc.UploadString("https://graph.facebook.com/me/events?" + "access_token=" + AccessToken, ser.Serialize(rawevent));
rawevent is a small object I wrote that puts together the elements of an event so I can pass it around my application.
I'm using a similar method using ser.Deserialize to parse the user data coming back from Facebook, so I believe this should work the other way too.
Setting the above code aside for a moment, I also have tried simply putting plain text in there in various formats and with differing levels of parameters, and nothing seems to work.
Is there something wrong with the way I'm approaching this? I've read over everything I could get my hands on, and very few of the samples out there that I could find deal with creating events, and when they do, they're not in C#.
I would appreciate any help on this. If you even just have a clean copy of JSON code that I can look at and see where mine should be tweaked I would appreciate it.
I have included a copy of what the ser.Serialize(rawevent) call produces below:
{"name":"Dev party!","start_time":"1308360696.86778","end_time":"1310952696.86778","location":"my house!"}
EDIT:
thanks to bronsoja below, I used the code below to successfully post an event to Facebook!
System.Collections.Specialized.NameValueCollection nvctest = new System.Collections.Specialized.NameValueCollection();
nvctest.Add("name", "test");
nvctest.Add("start_time", "1272718027");
nvctest.Add("end_time", "1272718027");
nvctest.Add("location", "myhouse");
wc.UploadValues("https://graph.facebook.com/me/events?" + "access_token=" + AccessToken, nvctest);

All the posting examples in the graph api examples in FB docs show using curl -F, which indicates values be POSTed as normal form data. Just key value pair like you did in your first example.
The error is likely due to sending JSON. If you are using WebClient you may be able to simply create a NameValueCollection with your data and use WebClient.UploadValues to send the request.

I've recently found that Facebook returns (#100) Invalid parameter when we are trying to post data when there is already a record on file with the same name. So for example, if you are creating a FriendList via the API, and the name is "foo", submitting another identical request for the same name will immediately return that error.
In testing events you probably deleted the "Dev party!" event after each test, or maybe changing the time since you don't want two events to collide. But I'm wondering if you duplicated your wc.UploadValues(...) statement just as a test if you would see that error again. You're either deleting your 'test' event or maybe changing names and didn't notice that two events with the same name might return the error.
What's really bad here is that the error comes back as a OAuthException, which seems very wrong. This isn't a matter of authentication or authorization, it's purely a data issue.
Facebook Engineers, if I'm right about how this works, it's a bug to return this error under these conditions, and this forum has many examples of related confusion. Please return more appropriate errors.

MS CRM 4.0 CrmService - Close a Task

I'm trying to work out how to use the CrmService to close a Task in MS CRM 4.0
I've tried to use the SetStateTaskRequest to set a Task's state and status to TaskState.Completed and 5. I also tried TaskState.Completed and -1, but no dice there either.
Either way, I only receive the ever-helpful "Server was unable to process request" exception on the CrmService.Execute attempt.
I can create and update Tasks as freely as I please. But I can't seem to set them to completed. It's frustrating.
I noticed that I can only set the state of a Task to Completed in CRM through the Close Task action. I was wondering if there is a separate CrmService call that I need to make to perform the Close Task action, rather than going through the CrmService.Execute method.
Oh: I'm logging into the CrmService with full permissions. So I can't see that it would be a permissions issue on the task item.
I can't think what else could be causing this issue. Any advice or even just a point in the right direction would be very much appreciated.
FIRST EDIT:
Thanks to grega g's answer for getting me to check the Detail field of the exception.
I now have a more detailed exception message. In XML Form:
<error>
<code>0x80040203</code>
<description>Invalid format of input XML for request SetStateTask: required field 'EntityId' is missing.</description>
<type>Platform</type>
</error>
Which is bizarre - consider my code (almost identical to greg g's:
SetStateTaskRequest request = new SetStateTaskRequest();
request.EntityID = gTaskId;
request.TaskState = TaskState.Completed;
// ETaskStatusCode is an enumeration of the status codes taken from the StringMap in CRM.
//
// ETaskStatusCode.Completed = 5 - I can confirm this is the accurate status value for a Closed Task.
//
// Also, I have attempted this code with -1, which the documentation claims should cause the status
// to automatically be set to the default status for the supplied state. No change there.
request.TaskStatus = (int)ETaskStatusCode.Completed;
SetStateTaskResponse response = CRMManager.CrmService.Execute(request) as SetStateTaskResponse;
Also, just to confirm that I have the right status code (and also share something I've found very useful when dealing with MS CRM), here's the SQL I use to determine the values for entity statuses.
SELECT
MSE.ObjectTypeCode,
MSE.PhysicalName,
SM.AttributeName,
SM.Value,
SM.AttributeValue
FROM MetadataSchema.Entity MSE
INNER JOIN StringMap SM on MSE.ObjectTypeCode = SM.ObjectTypeCode
ORDER BY MSE.PhysicalName, SM.AttributeName, SM.AttributeValue
I can confirm from the MS CRM web interface that the Status value that is associated with a Completed task is also named Completed. I can confirm from the SQL above that the value of this status, for a Task, is 5 - this is the value passed in from my Enum.
I can also confirm that gTaskId is being set to a valid Guid that references a Task that actually does exist, and is open at the time the close is attempted.
Curiouser and curiouser. Any thoughts?

Use SetStateTaskRequest class.
SetStateTaskRequest task2Close = new SetStateTaskRequest();
task2Close.EntityId = <taskGuid>
task2Close.TaskState = TaskState.Completed;
task2Close.TaskStatus = <some value>
try
{
SetStateTaskResponse r = (SetStateTaskResponse) crmSvc.Execute(task2Close);
}
catch (SoapException e)
{
//Use e.Details for more info than "server was unable ..."
}
This code should work (or let you see why error occurs)

Are you sure that when you are trying to close task you're passing status value which is valid for Completed state? Different status codes are only valid with their corresponding state codes. Can you add your source code and a portion of your state entity customization?

Found it!
Okay - reviewing my code above and the error message closely, my CrmService contained the property EntityID - but the exception was that the property EntityId was missing.
Somehow, my CrmService had its EntityId property renamed to EntityID.
Renaming the property fixed the problem. I still have no idea how that happened in the first place.
To be safe, I'll regenerate a new Service proxy to make sure that my properties are correctly named.
Looking through the code, it seems that someone did a find-and-replace on 'Id' and turned it into 'ID' - which incidentally is the naming convention in my workplace for Property fields that represent primary keys.
Thanks again to grega g for pointing out that the Detail property had the extra information I needed.