I'm trying to develop some SharePoint workflows for the company I work for, and I'm not too familiar with the ins and outs of the technology. Normally when I want to familiarize myself with something, I just play with it, look at the properties, find all the methods, etc.
When I fire up Visual Studio and try to create a SharePoint workflow, it gives me an error indicating I don't have a reference to "Microsoft.SharePoint.dll". Someone told me that it was normal to see that because you have to do all your development on the SharePoint Server itself if you want to do workflows. Is this true?
If so, is there anyone out there that has successfully developed SharePoint workflows in a multi-developer environment without resorting to any "hacks"?? Thank you for reading and your responses...
If you want to create a Sharepoint workflow using the Sharepoint Templates, you need to have a Windows 2003 or 2008 Server running Sharepoint. Essentially, that is true for all Sharepoint development: For it to be really efficient, you need to run Visual Studio on a Sharepoint Server. This in turn means that every developer needs his own Sharepoint server and then you have one additional "Staging"-Server where you deploy and test your combined solutions. Suddenly, that MSDN Subscription looks very attractive :-)
As for your Workflow learning question: I can highly recommend "Workflow in the 2007 Microsoft Office System" by Apress.
Yes, you have to do all your development on a the SharePoint server itself. Consider using a virtual machine and package up features that you can deploy to your staging and production environments.
http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx
http://www.wssdemo.com/Pages/EntDev.aspx
Yes, you can develop SharePoint Workflows, WebParts, etc. in a multi-developer environment without any hacks. I suggest you use
a MOSS 2007 VPC Image
Ankhsvn to use svn inside Visual Studio
and also the WSPBuilder Extensions
and maybe you should read What are your biggest complaints about Sharepoint? to see what you're up to ;-)
To learn SharePoint Workflow development,you can start at Step by Step Tutorial. Creating Workflows for Windows Sharepoint Services and MOSS2007
While it's true you need SharePoint installed on your development computer for most SharePoint development, you can get away without it for workflow development. Follow these steps:
Copy the SharePoint DLLs to your development computer (for workflow you'll need microsoft.sharepoint.WorkflowActions.dll).
Open Visual Studio and open the Toolbox tab
Add a new tab (call it SharePoint Workflow Items)
In the new tab, click "Add Items"
Click the "Activities" tab
Locate and add microsoft.sharepoint.WorkflowActions.dll
You'll see a few new tasks show up and already selected.
Once you do this, you'll be able to develop WF workflows that can use SharePoint-specific tasks. Deployment and testing the workflow is another task altogether.
Also, it was casually mentioned in this thread, but you cannot develop SharePoint workflows on a 64-bit SharePoint Server at this time. You will have to have a 32-bit Windows Server and SharePoint Server installation.
Here is a link to some SharePoint workflow how to videos.
http://chrisbarba.wordpress.com/2009/12/21/sharepoint-workflow-how-to-videos/
Related
I just revised my first job as a developer. In my workplace we developing mainly in c# language.
In my work place there is a lot of use in source control and TFS which I'm not familiar with, my question: suppose I want to learn TFS in my spare time at house, is it possible? I don't have a pro account, I have visual studio 2017.
I don't mean to online courses, I need to do a "hands on" practice, i.e I need tfc on my own pc if it's possible.
You can download and run TFS Express or use Visual Studio Team Services free for up to 5 users.
Or, ask if your company has a place where you can "play" on the live TFS instance, but in a test environment - I have setup separate "Team Project Collections" for people to experiment on.
Main issue: I need to develop an automated way to create new SharePoint pages when an item is added to a SharePoint list. For example, we have a list of projects, and when a new project is added to the list, we want a custom website for that project to automatically be created from a template.
What I've tried: I have been researching this a lot, and it sounds like SharePoint Event Receivers can do what I need. So I got Visual Studio (both Visual Studio and SharePoint are 2010). However, I still cannot automate my child pages. I get an error message when I try to do anything SharePoint-related in Visual Studio: "A SharePoint server is not installed on this computer. A SharePoint server must be installed to work with SharePoint projects."
My organization is not big on new software, so getting more than Visual Studio is probably not possible. In addition, I will not be granted admin rights, so I don't know if I will even be able to use Visual Studio. (Also I'm pretty sure my SharePoint is not locally installed, but I don't know much about software set-up/configuration...I just want it to work so I can code!) I do have full rights to the SharePoint site, so that shouldn't be an issue.
Is there a way to solve this issue with only coding in SharePoint? Or is there a way to do it with just Visual Studio (non-admin) and SharePoint?
In order to develop solutions for SharePoint 2010 you need to have SharePoint 2010 installed on your dev machine. You can install SharePoint 2010 Foundation which is free.
Before you start development you need to decide which kind of solution you gonna create - sandboxed solution or farm solution.
Sandboxed solution has some limitations in functionality but you do not need admin access to the server to deploy it, only site collection administrator rights on site collection.
On the other hand farm solution allows you to use any available SharePoint object model APIs. But to deploy it you need to have admin access to the server (or at least IT guy with admin access who can run some ps scripts).
The decision mostly depends on what are you going to develop. If you have some requirements which do not fit for sandboxed solution then you have to go with farm solution.
From what you've described I think sandbox solution is enough.
We have a multi-staged development environment, comprising Development, UAT and Production systems.
When developing solutions that will be migrated across all environments, we would like to be able to take advantage of all of the available development tools, including the SharePoint UI, SharePoint Designer and Visual Studio.
My question is, are the tools mutually exclusive?
Is it possible to create some components like Lists and Views using the UI and Designer, and then use visual Studio to create more complex features like web parts?
If so is there a specific process that you need to follow to make sure all of the tools play with each other for your solution?
In my experience... if it's possible to do in the UI, do it there. If it's not possible to do in the UI, but it can be done in Designer, do it there. If it's not possible in either the UI or Designer, then and only then, should it be done in Visual Studio.
If so is there a specific process that you need to follow to make sure all of the tools play with each other for your solution?
this is a important, but not easy to answer. For instance, I developed a custom web part that stored info in a list. At any point, a site owner could modify or delete the list from the UI and my web part would fail... to this day that's the way it is. It's a classic content management system conundrum, allow users to do their job while prohibiting them from breaking stuff. good luck!
We're looking into migrating to TFS 2010 in the next few weeks. However, we're unclear on what kind of tools are required for the team. We know developers need Visual Studio but what tooling is required for Project Managers and Testers that will ONLY need to manage work items? Do they also need Visual Studio to just view and edit work items?
Project Managers and Testers can use the following methods to access TFS 2010
The web access portal - this allows the ability to create/run queries of work items, and even view source/builds if they want
Excel/Project - Both have integrate with TFS. You are able to load work items directly into Excel/Project, edit them, and publish them back to TFS.
Visual Studio with Team Explorer only - This is a barebones installation of VS, with the Team Explorer only. It doesn't take all that long to install, but it will say "Visual Studio" when launched. Not sure if that is scary to testers/project managers.
Web access provides a good complete set of functionality, but having VS/Team Explorer will provide a rich client experience (read: faster, more responsive).
Additionally, in order to get the Excel/Project integration, you'll need at least the VS/Team Explorer installed on the client box, even if they never use VS. And you need a CAL (Client Access License) to use the web access portal.
So to summarize, TFS provides a lot of ways for the non-developer to interact with the system, but all of them require a CAL, and most of them require installing VS/Team Explorer on the client machine.
In short, they don't need Visual Studio. They can use Team System Web Access (formerly known as TFS Web Access) to do pretty much everything a developer can do, except associate a check-in with a work item. After you install TFS 2010, you simply browse to http://yourserver:8080/Tfs/web and you're in!
Project Managers (and all other team members) can also work with work items from Outlook using 3rd party TFS client embedded in Outlook: TeamCompanion www.teamcompanion.com. This way, assuming they otherwise use Outlook, they wouldn't need to change tools or use any additional tools at all.
As is the case with Excel or Project integration they would still need a TFS CAL and additionally a TeamCompanion license.
TeamCompanion supports much more than just work item management: Email/TFS integration, SQL Server Reports, SharePoint document integration and much more...
Full Disclosure: I am the Product Owner of TeamCompanon, so I may be biased :-).
There is a web front end which you can use to manage the work items. There is also integration to Excel and MS Project.
See http://msdn.microsoft.com/en-us/library/ms181304.aspx for more information on Team Foundation Clients
I am developing an Isolated Shell that caters to "designers/special content creators" performing specific tasks, using the Shell. As they operate on files, they need to be able to use TFS for source control. This is mainly due to the fact that Developers will also operate on the same files from TFS but using Visual studio 2008.
After looking and searching I still could not find Team Explorer to be available to Shell.
Asking on MSDN forums, lead me to the answer that "this is not supported yet in the Isolated Shell". Well, then the whole point of giving away a shell is not justified, if you want to use a source control system for your files. The idea is not to recreate everything and develop tool windows etc using the TFS provider API.
The Visual Studio Extensibility book by Keyven Nayyeri has an example, which only goes so far into this problem of adding a sc provider.
Has anyone worked on developing Visual Studio 2008 Isolated Shell applications/environment? Please provide comments, questions - anything that you have to share apart from the following threads, which I've already participated in.
Threads from MSDN forums:
Team Explorer for Isolated Shell
Is it possible to use Team Explorer in VS Shell Isolated?
Thanks for your answer. Yes you are right, we will acquire CALs for users without having to buy them Visual Studio, that's the direction we will be taking.
But I am yet to figure out how to make Team Explorer available to such users, inside Shell. So I am looking to find out the technical details of how that can be done.
I mean, I have a user, he installs my VS Shell application, he has no VStudio Team system on his machine. Now if I acquire CAL for TFS and install Team Explorer, do you think it will be automatically available in the VS Shell app?
Any ideas? have you worked on making this happen?
Thanks
It sounds like you are trying to allow the "special content creators" save files in TFS Source Control without having to buy them a license to a Visual Studio Team Edition -- correct me if I'm wrong.
If that's the case, unfortunately I believe that you can't quite do that. Your users still need a Client Access License ("CAL") to access TFS.
I think that you can acquire just CALs for your users without having to buy Visual Studio for them (I presume for less than a full blown Visual Studio would cost). At that point, you can just distribute to them the Team Explorer, which is a VS shell with nothing but TFS access components. That is available in your TFS server media.
I found this via Google. You might want to review it to decide your best options:
Visual Studio Team System 2008 Licensing White Paper
The only exception to the CAL rules I'm aware of is access to Work Items. Assuming properly licensed servers, anyone in your organization can create new Work Items or view and update existing ones created by them, using the Work Item Web Access component.
Just stumbled on this question, it might still be relevant to you.
You have the option of including the AnkhSVN (http://ankhsvn.open.collab.net/) packages and load it into your Isolated Shell. While there are some issues around it, with Subversion support, you could use SvnBridge to access TFS repositories. This might bring you a little bit closer to the process you are trying to achieve.