If you have tried to develop custom definitions/features for SharePoint in Visual Studio (using VSeWSS) and have run into one of the following errors, it’s most likely you have not completed the post-installation checklist.
The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8).
This error is mainly due to the WCF HTTP Activation feature not being enabled. Go to you’re Server Manager (or Control Panel -> Add Windows Features) and Install the WCF HTTP Activation feature under .Net Framework 3.0 Features.
After enabling the WCF HTTP Activation feature, if you run into the following error, chances are the service account running the SharePoint Central Administration v3 Application Pool does not have local admin access to the machine you’re trying to deploy to.
VSeWSS Service Logging Error: Access to the path ‘C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\VSeWSS 1.3’ is denied.
Logging failed attempting to write to C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log. This may occur because the VSeWSS WCF Service does not have local administrator permissions.
To fix this error, you need to provide admin access to the service account running the application pool. Most folks have suggested the use of Network Service to run SharePoint Central Administration which is not a good practice (and should be avoided, specially in a production environment). The best way to workaround this is to create a new Application Pool called “VSeWSS” in IIS. Go to Advanced settings in the AppPool and set the Identity to your local admin account. Now, under Sites, select “VSeWSS” and click on Advanced Settings. Change the Application Pool from “SharePoint Central Administration v3” to “VSeWSS” and perform an IISRESET.
You should now be able to deploy your custom features within Visual Studio without a problem.
Apart from working, watching college hoops and NFL games, I have no idea how time flies by so fast. Last week I was assigned to redo this “immoderate” InfoPath form that had no structure along with the lack of commendable functionality. This was my first InfoPath task, so though I’d share some nifty things I learned during the process.
1. ALWAYS create a well organized data source structure.
Because, if you want to change it later on, you are going to end up loosing existing data.
2. Getting the Current User in the local environment (for InfoPath Client)
3. Getting the Current User using Web Services (for InfoPath Web Forms i.e. SharePoint)
4. Getting custom code events to work on a web-based form
Go to Tools -> Form Options -> Security and Trust. Set the Trust Level to Full Trust.
5. Getting cascade drop-downs in a web-based form to populate secondary data source values.
Right-click on the primary drop-down box and select Properties. Go to the Browser forms tab and set Postback settings to Always.
6. Update existing form in SharePoint Library without having to create a new one.
Here, the trick is to create a unique file name for each form. You can use your own naming convention, but make sure to save the filename as a part of the data source. Create a new data connection to the Form Library and use the data field which contains the file name as the filename for the connection and make sure to select the “Allow overwrite if file exists” option. In the form, create an Update button and add a rule with the submit option that makes use of the data connection you just made. You’re done!
I got more, but they will have to wait till my next free tumblr time. :)
With the recent release of Microsoft 2010 Betas it’s been quite the talk about making the leap to the 64-bit world. For SharePoint folks it’s also a question of compatibility. As of now, SharePoint 2010 Beta requires 64-bit SQL Server and either Windows Server 2008 or Windows 7. If you are running R2, then you are out of luck as Microsoft has not yet released a hotfix. Also, not to mention the escalated hardware requirements, specially memory-wise.
So if you wanna give it a try (myself included) here’s a nice write up by Jie Li that might come in handy with the planing and installation itself. Good Luck!
SharePoint Newbie Issue #2
Deployed SharePoint Server 2007 on two different boxes running on farm environments and ran into permission issues. One was involving domain controllers and the other was thanks to “the always buggy” IE. However, one important thing I’ve learned is planning your deployment well ahead. One of the prime issues in the planning should be service accounts.
I was constantly told by multiple developers that the farm accounts required local admin access in the box your installing SharePoint. However, I came to realize this was not the case, at least in SP2. Having said that, all you need to know is that you’ve gotta well organized AD setup and running and the service account created and ready to go. Microsoft has a TechNet article on planning for service accounts which is quite lengthy and confusing. Here’s a more summarized and easy to understand version. READ IT! You’re gonna thank me and the writer later on!
http://cregan.wordpress.com/2006/12/08/moss-setup-service-accounts/
