I'm working with the Microsoft.WindowsAzure.MobileServices.MobileServiceClient class, trying to call a mobile API I've set up in--where else--an Azure Mobile Service instance.

My call looks something like this:

JToken response = await _mobileClient.InvokeApiAsync("myapimethodname");

And I'm trying to call an API containing pretty standard Node.js script that starts out like this:

var azure = require('azure')
  , qs = require('querystring');

/* Issued by Raspberry Pi:
    https://[blank].azure-mobile.net/api/photos
    With headers = "X-ZUMO-APPLICATION: [mobile_services_app_key]"
    Header contains the application key
*/

exports.get = function(request, response) {
…

Now, I've already successfully used this API using an HttpWebRequest and some code like this:

WebRequest r = WebRequest.Create("https://full_api_url_here");

r.Method = "GET";

r.Headers.Add("X-ZUMO-APPLICATION", "mobile_service_api_key_here");

using (var responseStream = r.GetResponse().GetResponseStream()) {

StreamReader sr = new StreamReader(responseStream);
string data = sr.ReadToEnd();
…

}

The point is, I know the API call works, and I figured using the MobileServiceClient class would be a lot easier and cleaner. But I'm getting this odd error.

I do a little Binging and find this bit of Azure Mobile Services documentation that states:

How to: Implement HTTP methods

A custom API can handle one or more of the HTTP methods, GET, POST, PUT, PATCH, and DELETE. An
exported function is defined for each HTTP method handled by the custom API. A single custom API code
file can export one or all of the following functions:

   
exports.get = function(request, response) { ... };
exports.post = function(request, response) { ... };
exports.patch = function(request, response) { ... };
exports.put = function(request, response) { ... };
exports.delete = function(request, response) { ... };

The custom API endpoint cannot be called using an HTTP method that has not been implemented in the
server script, and a 405 (Method Not Allowed) error response is returned. Separate permission levels can
be assigned to each support HTTP method.

The highlights are mine, so take note. I then look up documentation on the MobileServiceClient class and find this:

Again, the highlights are mine. Interesting.  

Finally, looking back at my script, I realize I've only implemented GET functionality.

Bingo.

My solution? I changed the API code like so:

function myApi(request, response) {

...

}

exports.get = myApi;
exports.post = myApi;

Pretty? No. But it works and it's resulted in much simpler code.

Found this blog entry: https://sharepointfieldnotes.blogspot.com/2010/08/making-your-sharepoint-2010.html

To summarize the information in the blog entry:

• Allowing manual records declaration for all site in a Site Collection is done in the Site Collection Settings, under the “Record declaration settings” topic.
• On the settings page, the “Record Declaration Availability” section allows an admin to turn manual record declaration on by default for all sub-sites.
• In the “Declaration Roles” section: if you select the “Only policy actions” option then manual record declaration will not be allowed. Selecting either of the other two options (“All list contributors and administrators” or “Only list administrators”) allows manual declaration.
• A Document library administrator can override the settings from the SPSite level using the record declaration settings for a specific library.
• You have to reference the Microsoft.Office.Policy assembly (in the GAC or in the ISAPI folder in the 14 hive) to get at the object model required to check some of the settings for Records Declaration.
• To check if the feature is enabled, use Records.IsInPlaceRecordsEnabled(SPList.ParentWeb.Site).
• To check if manual declaration is set for an SPWeb, check for and read the SPWeb.Properties[“ecm_SiteRecordDeclarationDefault"”] property. If the value is true, manual declaration is enabled by default.
• To check if a list is using list-specific settings, check for and read the value of SPList.RootFolder.Properties[“ecm_IPRListUseListSpecific”]. If true, well, the list uses list-specific settings.
• To check if Manual Declaration is enabled in a specific list, use SPList.RootFolder.Properties[“ecm_AllowManualDeclaration”]. Remember that checking only for this overlooks the fact that the Manual Declaration may have been set at the SPSite level.
• To validate Manual declaration is enabled, check that either:
• List-specific settings are NOT set AND manual declaration IS set at the SPSite level; or
• List-specific settings ARE set AND list-specific settings are set to true.

The referenced blog post provides code samples to check values using the logic described above. The rest of the blog post goes on to show how to check if a specific user can manually declare a record; how to check if a file is a record; how to actually declare—or undeclared—and item as a record (using code); and how to determine record restrictions (settings that can also be set using the UI’s Record Restrictions section.

In any case, I highly recommend reading through the post I’ve referenced above. I’ve summarized the information here just in case the referenced post gets taken down for some reason. But that post does a much better, much more thorough and useful job of explaining how this all works.

Here is Mr. Yadav’s original code:

using (SPSite siteCollection = new SPSite(https://{your site url})) {
   
  //enable client integration 
  siteCollection.WebApplication.IisSettings[SPUrlZone.Default].EnableClientIntegration = true;
   
  //disable client integration 
  siteCollection.WebApplication.IisSettings[SPUrlZone.Default].EnableClientIntegration = false;

  siteCollection.WebApplication.Update();

}

And here is my version, converted for use via PowerShell:

  // Initiate a new assignment store so we can clean up our SP objects afterward

  $gc = Start-SPAssignment

  // get a specific Site Collection

  $s = $gc | Get-SPSite https://{your site url}

  // Use the IisSettings object on the WebApplication to update EnableClientIntegration

  // enable client integration

  $s.WebApplication.IisSettings[[Microsoft.SharePoint.Administration.SPUrlZone]::Default].EnableClientIntegration = $true

  // disable client integration

  $s.WebApplication.IisSettings[[Microsoft.SharePoint.Administration.SPUrlZone]::Default].EnableClientIntegration = $true

  // Make sure to call update on the Web Application

  $s.WebApplication.Update()

  // And dispose of the SPAssignment (i.e. the Site Collection object)

  Stop-SPAssignment –Identity $gc

Well, you get the picture. I’m pretty happy about finding an answer to this one, as it was just one more blocker to getting a rush job done for a client. (Isn’t that always the case?)

Anyways, here’s the link to his original post, from July 6, 2009: https://www.martinhatch.com/2009/07/call-to-searchserviceinstanceprovision.html. I’m reposting here just in case I forget where to find the original post.

I don’t know that I ever would have figured this one out, because the error itself it completely useless. But the fix was this:

For the account credentials, when turning on the Search service, use the fully qualified domain credentials. I.e., rather than myuser, use mydomain\myuser. Apparently, this is one place where SharePoint can’t figure out that—even though the rest of the farm is running on domain accounts—this credential set should be a domain account, too.

Go figure.

Ran into this error while trying to go through the Claims Walkthrough: Creating Trusted Login Providers (SAML Sign-in) for SharePoint 2010 tutorial, and on the first step! I always hate these kinds of “tooling” errors, since they don’t even provide any learning for the task at hand. They are just a hassle that distracts me from actually working on the tutorial. The fix is quite simple, but I couldn’t find an answer using the normal searches on Bing (or Google, for that matter.)

The full error is as follows:

“Error: this template attempted to load component assembly ‘Microsoft.IdentityModel.Tools.VS, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL’. For more information on this problem and how to enable this template, please see documentation on Customizing Project Templates.”

…Just in case anyone is searching on all or part of the error text. And yes, I even tried searching for the “documentation on Customizing Project Templates.” Not useful at all for resolving this error.

In any case, when I attempted to complete Step 1, task 5b (“Select the ASP.NET Security Token Service Web Site template”) I discovered that the required template wasn’t installed locally. So I clicked the “Online Templates” option, found the “ASP.NET 3.5 STS Template” option, changed the name of my new local project (from the default of “STSWebSite1”), and clicked OK. The template attempted to load, and then VS gave me this error.

I tried a number of things, which I won’t go into here, but finally decided that maybe the issue was related to tooling. So I downloaded the Windows Identity Foundation SDK 3.5 (the template specifies that it’s for v3.5 of the .NET framework, but v4.0 may work just as well—I didn’t try it.) I installed the SDK—making sure to close Visual Studio first (actually, the installer wouldn’t let me continue until I’d done that part)—and voila, the next try at downloading the ASP.NET STS Template worked!

Ok, that was sarcasm. And not very well done, at that. Actually, I hate this error because it’s so vague, and because at least half the time I’ve seen it, the faulting method doesn’t actually contain the code that caused the root problem. It just happens to be where everything finally blew up. And in fact, that was the case here.

So that you don’t have to keep thinking to yourself, “Would you please just get to the point!?”, I’m going to give the solution, then the cause, and then I might go a little into the process of how we got there.

The Solution

There are a few possibilities (as always):

1. Try turning off Verbose logging. This one doesn’t seem to always work, but it certain instances it does. Apparently, if Verbose logging is turned on, SharePoint uses one of the utility methods that we found had the bug related to using StackFrame and StackTrace.
   
2. Don’t do it. Find an alternative. I hate that this is the answer, but we actually tried option number one and initially got it to work. With further testing, however, we hit the same error again, but this time caused by a separate utility method that did basically the same thing with StackTrace and StackFrame as the first method. And that was with Verbose logging turned off.

That’s it; really. You may get it to work, and please, please, please: if you did encounter this error and still found a way to make the WCF call work (well, the instantiation, actually; we had no trouble getting the WCF call to go through), please let me know how you did it.

Here are two alternatives:

1. Use the SharePoint 2007 web service API, which is pretty robust.
2. Use a standard web service hosted inside a SharePoint web app.

In this customer’s case, they wanted to due some special configuration magic that would have been much more difficult without the special configuration file they’d designed. So, they opted for creating a web service hosted inside one of the SharePoint web apps (I’m not going to give too many specifics about their architecture, but the point is that this option worked.) As I said, however, the SharePoint 2007 web service API is fairly robust. With some planning, you will probably be able to accomplish everything you want just by making use of it. A quick search on Bing will locate some really helpful resources for you, but for the really lazy, here are some samples:

• Automate Web App Deployment with the SharePoint API (MSDN Magazine; Ethan Wilansky, Paul Olszewski, Rick Sneddon)

• Getting Started With SharePoint Web Services (InfoQ; Trent Swanson)

• SharePoint 2007 Web Services (Tony Testa’s World; Tony Testa)

• Inside SharePoint - Extending Office Applications with Web Services (TechNet; Pav Cherny)
  

The Cause

There is a documented bug in SharePoint 2007 with one of the utility methods. The method itself seem innocuous enough: all it does is list out the stack when asked using the .NET StackTrace and StackFrame objects. Unfortunately, due to various factors—most of which I’m not privy—these .NET objects may not be instantiated.

I think (and this is just presumption, which is why I italicized those two words) that StackTrace and StackFrame being null may be related to the fact that most SharePoint 2007 .NET code is just a series of wrappers for unmanaged COM code. Thus, I’m guessing (again, notice the italics) that the StackTrace and StackFrame objects are not instantiated in all circumstances. I mean, they’re not as fundamental as, for instance, the Object class. But I digress. Plus, I’m right at the edge of what I know and what I blatantly don’t, and if I tread any further, that will become painfully obvious.

In any case, due to some strangeness in how the SharePoint classes get instantiated when called by a WCF service, the StackTrace and StackFrame objects don’t get instantiated, but a couple of SharePoint utility methods that use them do get called. And since those utility methods don’t take into account the fact that StackTrace and/or StackFrame might not have been instantiated, they call methods on the null objects, causing the “Object reference…” error to be thrown.

Other Things We Tried

• We started by making sure the WCF call was making it to the endpoint. Once we established that, we knew would should be able to rule that piece out. Besides, the error was happening in the SharePoint code, after a considerable amount of other code had already been called and run.
• We noticed that the HttpContext and SPContext objects were null, and thought that might have something to do with it. We created context manually by creating an HttpRequest.
• Since the error was happening inside custom feature-related code, we tried adjusting the settings to not activate any features. We still got the error, but now we could see it actually happening in the SharePoint utility class. This was almost more confusing, since our first thought was, “That doesn’t make any sense—it’s just a method in a utility class that displays StackTrace information. I guess the lesson here is not to overlook what’s right in front of you.

One of the oddest things was that we initially didn’t find any mention of this bug on the web. Actually, my customer was the one that found a brief mention of turning off Verbose logging while searching archived forum postings. This led us to search our internal bug database, where we found the SharePoint bug documented.

And just in case you’re hoping this might be fixed in SharePoint 2007, I’ll let you know that this particular bug was marked, “Postponed”. On the plus side, it is confirmed as fixed in SharePoint 2010.

HTH,

Chris

• Placing my DLL into the GAC;
• Checking what else my assembly might be referencing;
• Changing the security rights on the “Temporary ASP.NET Files” folder;
• Viewing the assembly bindings using SysInternals Process Monitor tool;
• Setting the registry to display assembly binding information;
• Setting the WSS Trust level to “WSS_Medium”;

and several more (including all of the standard SharePoint steps of placing the assemblies in the “bin” folder and adding a SafeControl entry.) None of them worked, and some of them were actually bad ideas (e.g. changing the security rights on the “Temporary ASP.NET Files” folder.)

Finally, I got in touch with one of my colleagues—a guy who is often able to help me through such problems—and he diagnosed the issue right away.

Change the WSS Trust Level to “WSS_Full” or Place DLL in the “app_bin” Folder

The fix I actually implemented was placing my DLL into the “app_bin” folder in my web application’s root. The reason this worked is actually related to the other option: changing the WSS Trust level.

My colleague pointed me to the WSS Trust Policy file. Mine was located in “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_mediumtrust.config"; you should be able to confirm the location of your by looking in one of the web.config files in your SharePoint root folder (search for “<trustLevel”.) Reading through that (not an easy read, by the way), I discovered that the trust levels defined in “wss_mediumtrust.config” contain no mention of the “bin” folder.

This is why putting the assembly in the bin folder doesn’t work, even when setting the trust level to “WSS_Medium”.

The “app_bin” folder, however, is included. This isn’t exactly recommended, however. The actual answer should be to either:

• Set the trust level to “WSS_Full”; or
• Modify the “WSS_Medium” policy to include the “bin” folder.

Hope that helps someone else.

- Chris

1. Open regedit.exe.
2. Navigate to HKLM\SOFTWARE\Microsoft\Fusion.
3. Add a new DWORD entry named “EnableLog”.
4. Set the value of the entry to 1.
5. Reset IIS (at a command prompt: “iisreset.exe /restart”.)

Recreate the error. The ASP.NET error text should now include assembly binding information.

Since I don’t do it very often, I can never remember everything I need to do to get DNS set up correctly when I create a new MOSS VM for testing or development. It’s easier to set the entire thing up to run on a single server to keep it insulated from everything else I might be working on, and it doesn’t suck up as many resources on my VM host as a multi-server farm might (i.e. DC/DNS, Web Server, SQL Server.)

So here are some notes for next time:

1. Install at least two NICs (physical or virtual adapters) on the box. One can be for external access (i.e. so you can get to the Internet), and the other for local routing (on-box, in this case) only.
   
1. Set the External NIC up so that it retrieves an IP address from your network DHCP server. For a home network, this would probably be the gateway router that acts as a DHCP server. Generally, you can just select, “Obtain an IP address automatically” and “Obtain DNS server address automatically”, as shown below.
   
   
   
2. Set the Internal NIC up with a static IP address. Then specify the DNS server address as either 127.0.0.1 (the loopback address) or as the static IP address you’re giving to this NIC.
   
   
   
2. DNS – must be installed on the server (as well as Active Directory).
   
1. Forward Lookup Zone: this server will provide name resolution for computers listed in this zone.
   
1. Zone can be authoritative: means that this server is the primary place to get name resolution for the machines listed.
   For this (assuming the zone doesn’t exist already), create a new zone with the name of the domain for which this box will be authoritative. E.g. “mydomain.com”.
2. Or, the zone can be non-authoritative: by creating a “stub zone”, this server will get its lists of servers from another DNS resource.
3. Name-to-IP or IP-to-Name: both types of resolution can be handled with a single entry.
   
1. First, right-click your new zone listing under “Forward Lookup Zones” and select “New Host (A)”.
   
   
   
2. This displays the “New Host” dialogue window.
   
   
   
3. The Host Name—the name of your site (e.g. “moss” for “https://moss/” or “https://moss.mydomain.com”) goes in the first box. You don’t need to add the “.mydomain.com” part; that will get added automatically and entering it here will cause it to double-up (e.g. “https://moss.mydomain.com.mydomain.com”.)
4. The IP address goes in the second box. This can be 127.0.0.1, but it’s better if you have an address that isn’t the loopback address, as that can cause other issues. Use the address you assigned to the Internal NIC.
5. Checking the first checkbox (“Create associated pointer record”) causes a record to be created that allows reverse-lookup as well. So, typing “https://192.168.x.x”—or whatever the actual IP address of the box is—will cause the site to still be found as “https://moss.mydomain.com”.
   
4. Once you get this far, you should be able to ping the hostname and get a response from the IP address you chose. You should also be able to ping the IP address and get a response.
   
2. Reverse Lookup Zone: don’t bother with this for now.
   
3. IIS Settings: you may need to create a host-header entry for your web application using the properties window in IIS.
   
1. Find the node in the tree for your web application, right-click on it, and select “Properties”.
   
   
   
2. In the Properties dialogue window, select the “Advanced…” button on the “Web Site” tab.
   
   
   
3. Click the “Add” button…
   
    
   
4. And add an entry by specifying:
1. The IP address (or leaving as “All Unassigned”);
2. The port (“80” is the default for HTTP traffic; “443” is the default for SSL traffic);
3. And the Host Header value. For the Host Header, enter the name you want to use when going to the website. In the existing entry above, I’ll be able to type “https://moss.mydomain.com” to get to my SharePoint site.
   
   
   
4. Multiple Host Header values can be added for a single web application. In addition, each Host Header can be bound to its own static IP address. In order to do this, however, you’ll need to add additional IP addresses to one of the box’s NICs. That can be done using the following dialogue window:
   
   
   
   This can be opened by clicking the “Advanced” button on the Internet Protocol (TCP/IP) Properties dialogue window.
1. Right-click on the Internal NIC';
2. Select “Internet Protocol (TCP/IP)”;
3. Click the “Properties” button to view Internet Protocol (TCP/IP) Properties;
4. Click the “Advanced” button.
5. Select the “DNS” tab.
   
4. hosts file: If all else fails, or you’re still having some odd routing issues, or for some reason one of the host names you’re trying to use won’t resolve to the right IP address, you can try adding a host-name-to-IP-address matching directly in the host file (c:\windows\system32\drivers\etc\hosts; the file has no extension.) It’s a simple text file; open it in a text editor like Notepad.exe and add a line like this:
   
   111.111.111.1          myhostname.com
   
   (Note: that’s a tab between the IP address and the host name.)

Ok, hope that helps next time you’re trying to get a new machine set up—physical, virtual, or otherwise.

As noted by Nishand in a blog posting several years ago, SharePoint 2007 had a number of peculiarities around when a instance of an object was needed versus when it wasn’t. In SharePoint 2010, this has not been changed.

I just had a client ask me about this specific example:

In order to change the default page of an SPWeb that is not a PublishingWeb, you have to set the WelcomePage property of the SPFolder class. In this case, that SPFolder class can be obtained via the RootFolder property.

As with most programming, the quickest route would seem to be the ideal choice to make; thus, the following should work like a champ:

web.RootFolder.WelcomePage = “NewWelcomePage.aspx”;
web.RootFolder.Update();

And yet while stepping through the code, it was plain to see that this code was not working. It turns out that, due to some peculiarities of the code within the SPWeb and SPFolder classes, it is necessary to actually create and hold an instance of the SPFolder class whose WelcomePage value you want to change. Thus, this code does work:

SPFolder folder = web.RootFolder;
folder.WelcomePage = “NewWelcomePage.aspx”;
folder.Update();

My guess is that this is due to the way the SPWeb object is getting at the SPFolder object represented by RootFolder. Namely, it isn’t unless that object is specifically requested. Thus, a call to web.RootFolder.WelcomePage would directly access the resource indicated by the WelcomePage property and allow the getter to retrieve the current value. Since, however, the SPFolder class is what actually handles updating this value, however, only after getting an instance of the SPFolder object represented by RootFolder will a process have the necessary means for updating the value of RootFolder.

And an SPFolder instance of RootFolder isn’t actually retrieved unless it’s specifically requested.

From a resource standpoint, it makes sense. From a usability standpoint, it leaves a lot to be desired.

HTH,
Chris