As we approach the Holiday weekend, I suspect many of you will be installing SharePoint 2010 for the very first time… and a good portion of you on Windows 7.
Personally, I found the MSDN article Setting Up the Development Environment for SharePoint Server to be very helpful, and was my main point of reference when I performed the installation But I did have to work my way through several steps that were simply not very clear, and troubleshoot at least one error. In this blog posting, I will help walk you through some of the confusing/unclear steps, and help you overcome (maybe avoid altogether) the error that I encountered.
Note - Remember, this posting assumes that you are following the steps outlined in the MSDN Article: Setting Up the Development Environment for SharePoint Server
Step 1 is strictly geared towards helping you choose your operating system. This posting specifically focuses on installing SharePoint 2010 on Windows 7… remember it must be a 64 bit version and you should have at least 4GB of RAM.
Step 2 is where the confusion begins:
- The very first sub-step refers to a SharePoint.exe file that for many of us was nowhere to be found. This SharePoint.exe file is actually the single executable contained within the ISO image of the SharePoint 2010 Beta 2 download… for me the file was titled: en_office_sharepoint_server_2010_beta_x64_x16-19249.exe. Depending on the build and version you downloaded, it could have a different name.
- Copy this file locally (do not run it), they suggest copying it to C:\SharePointFiles
- Given the complex name I chose to rename it to SharePoint.exe you may consider doing this as well as it makes the following steps easier.
- The second sub-step instructs you to run a command to extract the installation files. It shows you 2 sample commands, one of which is:
Here simply replace SharePoint with the name of the executable, the command should work just fine if you’ve renamed the executable to SharePoint.exe
- Perform sub-steps 3 to 5 (these should be pretty straight forward)
- Skip sub-step 6 altogether…it only applies to Vista
- Install each of the pre-requisites outlined in step 7.
- Copy the script in step 8 into Notepad and remove all line breaks. It should look something like follows:
start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-RequestFiltering;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI;WCF-HTTP-Activation;WCF-NonHTTP-Activation
Copy the script and execute it in the command prompt. (I suspect you may receive several errors during this step if some of the services are missing or have already been preconfigured) Sub-step 9 should help you troubleshoot any errors you encounter during the activation of these services.
Restart your computer and on to Step 3.
Step 3 is pretty straight forward and should not give you much of a headache as long as you follow the instructions. There is a required hotfix, which they didn’t list in the instructions… I’ll get to it shortly:
- Know that you must choose “Standalone” configuration in sub-step 3. If you run into errors after choosing “Server Farm”, you are on your own.
- Stop on sub-step 5 and install SQL Server 2008 KB 970315 x64 per the instructions. But do not run the Configuration Wizard just yet.
- Download and run the WCF hotfix from http://go.microsoft.com/fwlink/?LinkID=166231. If you don’t you will receive an exception while running the Configuration Wizard (more details on the error here and here.)
- Run the SharePoint Configuration Wizard.
Steps 4 and 5 instruct you to install Visual Studio 2010 and Create a Hyper-V virtual hard disk from the installation.
It would be a shame for you to leave out installing SharePoint Designer 2010 Beta 2.
That should be it… Have fun coding with Visual Studio 2010 and SharePoint 2010.
A couple of weeks ago I demoed an example of how to create a basic SharePoint 2010 “Change Site Title” feature using Visual Studio 2010. A video of the demo is now available on the SharePoint Tech Dives site at http://www.sptechdives.com/?p=185
I came across the following MSDN article while browsing through the MSDN SharePoint 2010 documentation. It provides step by step instructions on setting up a SharePoint 2010 dev environment. Definitely cool content, check it out: Setting Up the Development Environment for SharePoint Server (http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx)
This is a really cool concept that’s new in SharePoint 2010. I was going to take a stab at describing it… but the presentation is already starting and I think the abstract is more than adequate:
”SharePoint 2010 adds a new deployment model for SharePoint called Sandboxed Solutions. It is a controlled solution packaging format that offers SharePoint Server Farm owners a way to easily mitigate risk that custom code will cause issues for them. It does this by restricting the API’s that can be called and governing resources that can be used…”
- Creates a balance of stability (for IT admins) and agility (for developers) when developing, implementing, and testing solutions.
- IT admins can control which servers in the farm will be allowed to run Sandbox Solutions
- Only access to a Certain Subset through the proxy
- No access to enterprise class objects
- Code Access Security Limits
- AspNetHostingPermission.Level = Minimal
- Can create a “fully-trusted proxy” that will allow us to reach outside the boundaries
- Sandbox solutions deployed at the Site Collection Level
- Site Collection Admins determine which Sandbox solutions run in their site
- From Central Admin Can
- Block Solutions
- Quota Templates
- Resource Monitoring
- When deploying from Visual Studio 2010 will have to options to deploy solutions
- Deploy as Sandbox Solution (selected by default… hint hint.. this is the way they want us to go)
- Deploy as Farm Solution
- VS adds and removes the Partially Trusted Callers based on Boolean value of the project properties which specifies if this is a Sandbox solution or not.
- Full Trust Proxy
- Create a class that inherits from SPProxyOperationArgs
- Class only passes arguments (Get and Set)
- Create another class that inherits from SPProxyOperations
- Override Execute Method
- Your logic goes here
- Takes in the SPProxyOperationsArgs class
- Override Execute Method
- The Full Trust Proxys must be registered on the farm via code (at least that is what he demoed… not sure if there is another way.)
- Can execute the the full trust proxy code by calling SPUtility.ExecuteRegisteredProxyOperation from the Sand Box solution class.
- Create a class that inherits from SPProxyOperationArgs
- Supports Load Balancing across specific servers on the farm
- Can monitor and set limits on:
- CPU, Memory, SQL, Exceptions, Critical Errors, Handles, Threads, etc..
- Can allocate “Resource Points” to solutions that if consumed by a specific resource will not allow that solution to run for the rest of the day. (I’m sure there will be plenty of arguments over this)
This is the second presentation I decided to attend. Presented by speaker; Paul Andrew from Microsoft. I’m posting the highlights from the presentation in the form of notes. As time allows over the coming months, I look forward to providing more in depth information on many of these:
- Steve Creates a custom Web Part using Visual Studio 2010
- Inserts the web part outside of a web part zone, in the content/wiki area of a page (very cool!)
- Business Connectivity Services (Replaces Business Data Catalog)
- Ability to Connect to .NET Data / .NET Types
- SharePoint List Improvements
- Cascading and Restricted Deletion (shown in demo)
- Formula Based Validation (Excel like)
- Lookup to multiple columns
- List Index Auto Creation
- List Query Throttling (allows IT Admins to set limits/restrictions on number of items in views)
- Allows you to specify validation messages on fields for list… In other words, you don’t just specify that a field is required, or the format; but you can also specify the message that gets displayed to the user if it doesn’t meet the requirements. (Fantastic)
- XSLT based View creation rather than CAML
- Client Object Model which runs on remote machines. Helps overcome issues with network load. Sample: Create reference to SharePoint Context > Load > Execute Query (call gets made which gets context info) > Execute Logic (such as UpdateTitle or AddItem) > Item.Update > Execute Query (call gets made again and change is applied)
- Events Improvement
- After-Synchronous Events
- Site Scoped Events
- Web Creation Events
- List Creation Events
- Workflow Improvements
- VS 2010 Initiation and Association Forms (shown in demo, much much easier than it was before)
- Import SPD Workflows in Visual Studio
- Visio 2010 Workflow Design
- Many more, at least another 15… (could not get them all, changed slide to quickly)
- Sandboxed Solutions
- Easy Deployment
- Iterative Deployment
- Solution Gallery
- Way of Uploading the WSP into SharePoint
- Does not sit on the file system of the machine until someone uses that piece of code until someone approves
- Monitors Process and Restricts API Calls using code access security
- If the code uses more resources than its permitted it gets shut down
- There are several rules that can be created and applied to the solutions to make it easier to test these without bringing down the farm.
- Processes run against proxy instead of directly against SharePoint API (will need more info about this, but sounds impressive)
- Able to log the commands that are being routed through the proxy to among other stuff.
I’ve posted the PowerPoint deck of the presentation Apollo and I gave yesterday at the Houston Tech Fest: click here to download a copy.
It was a great event and I look forward to participating again next year. Thanks to all who attended our presentation.
This is a fairly common and non-descriptive error that continues to surface more and more as the SharePoint developer community continues to grow. Surprisingly, I’ve found very little information in the web regarding what I believe to the most common cause and solution (hence this blog post).
Many things can trigger this error, and as you might expect by the description the error is security/permissions related. I’ve seen it most often, when browsing the Site Features and Site Collection Feature pages… but it has been known to take down a whole site; although mostly (and luckily) in dev environments.
So why do I keep referring back to development? And more importantly, what is this “most common” cause/solution? Its mostly tied to “drag and drop”; when you drag and drop files, permissions usually go with them (albeit there are a few exceptions.) With development rarely taking place directly in the 12 hive features, or layouts folder; its shouldn’t be surprising to see developers (and administrators alike) deploying and often testing changes to features by dragging and dropping files from their Desktop, My Documents, or project folders. Naturally this approach doesn’t follow best practices, but I wont deny having made the mistake while testing a quick change to a feature or elements xml file in a development environment. All updates to production environments should be done via WSPs.
So how do you solve the problem? Finding the culprit shouldn’t be too difficult, think of any items that have been recently deployed/updated. Cant think of any, search for any recently updated files of folders. If you do think of or find any; check the permissions and make any required modifications; also consider redeploying them via a WSP.
This week, I gave a presentation on “Editor Parts” at Houston’s SharePoint User Group event. It included a live demo on how to build an Editor Part that displays a dropdown of all of the Lists for the site where the corresponding web part is being deployed. I’m including links to download the presentation and source code below:
Let me start by saying that while executing code via RunWithElevatedPrivileges may help you overcome certain “access denied” exceptions in your code, using it should be the exception not the norm. This is not meant to be a “how to” posting on RunWithElevatedPrivileges, there are plenty of articles out there that already cover just that. Instead I’d like to focus on a subject that I consider to be just as important; when is the right (and wrong) time to use this command.
I recently wrote an article for the MSDN on “Securing Application Pages for Windows SharePoint Services 3.0”. In it, I provided several code samples on how to do just what its title implies; some of which included calls to RunWithElevatedPrivileges. A respected colleague was quick to point out a concern; that some of the information contained in the article (specifically references to RunWithElevatedPrivileges) might result in certain individuals using the command without giving it sufficient thought.
The very reason I wrote the article, stems from how often I’ve seen this command used, and the security risks it presents. I’d hate for the article to be seen as a case or excuse for calling this command, when in large part is the very thing it tries to protect developers from.
SharePoint provides a very extensive and well thought out API, at least from a security standpoint . It uses impersonation, meaning that the code you write will execute under the context of the user viewing the page where your code resides. If you write a web part or application page that reads or writes information from a SharePoint List, Library, or Site that does not grant the user such rights; your web part or application page will throw an error… as it should. Your first instinct should not be to rewrite your code so that this logic executes via the RunWithElevatedPrivileges command. Doing so might be considered a hack.
That’s not to say using RunWithElevatedPrivileges is a “hack” every time, there are certain unique cases where you don’t have much of a choice. But first consider checking if the user has the necessary permissions via the DoesUserHavePermission method of either the SPSite, SPWeb, SPList, or even SPListItem your accessing with your code, and avoid doing anything further on that item if the method returns false for the required permission level. Alternatively (although often cause for debate) consider handling the access denied exception. Ultimately, don’t hurry too much writing your code, the quickest way is not always the best way.
Happy Coding. Oh.. and thanks for the pointer Matt.
An article I recently wrote has just been published on MSDN. It covers the basic principles of securing application pages, and why they are often at risk; as well as providing code samples on how to properly secure your application pages, including:
- How and when to validate page requests
- How to verify Base Permissions
- How to verify Role Definitions
- How to verify Group Memberships