I'm trying to understand how Visual Studio, SharePoint Designer and Foundation work together

Question

I'm working in a user area and am limited to Sharepoint development on the client side only. This means that all custom forms and their associated scripts will live in site libraries instead of on the server. Taht's my biggest limitation. In researching the appropriate development tools, I've run into more questions than answers, and am hoping to get some real-world experience from others managing a similar situation:

1.) I've heard that given the choice between SPDesigner and Visual Studio, I should avoid Designer. However, no one can tell me why. If I know Microsoft, I would guess that the drag-n-drop nature of the interface generates some incredibly bloated code compared to creating something myself in VisStudio. Is that a correct assumption? What are some of the other (if any) pros and cons of using Designer over VisStudio? Are there instances where one is clearly desirable over the other?

2.) Assuming that I do get special dispensation from IT to orderm and run Visual Studio (and I'll ahve the choice between v10 and v11), can I do all my development pointing to the site level (of which I'm an admin) instead of at the farm level? My requirements dictate that nothing be deployed on the server. Can anything developed in VisStudio live in the doc libraries? or must it all be housed at the server level?

3.) Does VS require any sort of permissions granted, or does SP magically know what kinds of permissions to grant to VS?

4.) Where does my code eventually need to live? in the site's document library? or can I put it somewhere in my sites where it would be available to all subsites...in the same way that the site columns are accessible to any subsite? Again, though this time regarding where code is deplayed, does VisStudio have limitations that Designer doesn't and vice versa?

5.) Knowing very little about Designer and Visual Studio, can anyone recommend some good online tutorials or resources? or at the very least, an effective Google keyword or two that'll kill some of the noise I'm finding.

Answer 1

That's a lot of questions in one question :)

1) For a developer, you quickly feel limited in designer, because most development tasks require visual studio. Designer is really more a tool for tweaking and adjusting an existing environment, not so much for developing. But sometimes you need it, so it's a matter can't living with it, but also can't living without it :) I don't like it either, it's unstable, some features just don't work at all and other give non helpfull errors. But once you know your way around the things that DO work, it's ok.

2) You need to setup a seperate development environment, detached from your production environment. Ask for a virtual machine on which you can install SharePoint. When that's not an option; only sandbox development remains; all other things will impact your farm in one way or another. A simple deployment will reset your application pools, making your sites unavailable for a little while. When working sandboxed, you'll quickly find out there are some pretty challenging limitations on what you can or cannot do.

3) The account you use to run VS determines the rights you've got in SharePoint. Typically, you would develop on a seperate server where you're most likely a local administrator of some sort. Then you would deploy into a test environment in which rights are setup to match the production environment, so you can test how your code behaves when it doesn't have admin rights.

4) Depends on what you're deploying. Sandboxed solutions are only avaiable in the site collection you deploy the solution in. But normal solutions can be either web, site, webapplication or even farm scoped. Code doesn't live in a document library, but in the assembly cache, bin folder or sandbox. That's how a basic ASP.NET webapplication also works, I'd advice to start there when you've got completely no clue about these things (which it seems like if you have to ask such a thing, nofi).

5) Start with .NET basics, there are several certification courses for .NET framework development. Those will teach you about how .NET works, how Visual Studio works and how to make use of the .NET components. After that, do some ASP.NET development / courses. And after those; you can start with SharePoint. I don't recommend starting with SharePoint when you've got no .NET experience at all. That's going to be a steep learning curve.

Answer 2

I have recently started off with SharePoint also and will share with you what I've gathered so far:

1) I started off using Designer, but now only use it for very simple tasks (adding a list, etc.). In my experience, it is prone to crashes and certain tasks simply don't seem to work for me when they are done via Designer:

• creating a site lookup column in a parent site and referencing it in a list on a subsite
• modifying the XSL for a list view (Designer seems to mangle xsl:choice tags for me).

2) Sounds like you need to deploy "sandbox solutions" and avoid "farm solutions". I'd go with most recent Visual Studio version.

3) I need to run Visual Studio "as Administrator" for SharePoint projects. I also needed to install SharePoint on my development machine. I believe there are workarounds for if you have Visual Studio on one machine and SharePoint on a server but then debugging gets hairy, etc. I've found a happy place where I develop against my local sharepoint instance and then only deploy things to the server when I am good and ready to do so.

4) Your code basically lives on the filesystem of the server. "Solutions" containing "Features" are deployed, then those Features are "Activated", then they can be used.

5) It really depends what it is you'd like to do. SharePoint is very powerful in that it provides many built-in features and allows for all kinds of customization. Your requirements should drive your quest for tutorials.

Good luck.

Answer 3

I know this is an old thread, but I thought I would share my experience.

I use both VS and SPD. I am not sure it is an either/or proposition and I don't know why someone would tell you to avoid it. I think knowing both tools is important.

For instance, SPD can create some pretty complex workflows that are easy to deploy. The workflows are wizard-driven (both a blessing and a curse depending on your level of experience). However, SPD WFs don't allow you to run parallel tasks or loops, create state machine WFs, create reusable WFs, or attach workflows to content types. You'll need VS for that.

I had to create a master/detail form for a project. SP and SPD OOTB do not support this. I had to create a user control in VS and wrap it in a SP web part.

I will usually develop in SPD unless it will not support what I need to do. SPD interacts directly with your SP instance and is design specifically for SP. SPD is also far more approachable for non-developers.

When you create SP solutions in VS you need to know how to develop in the .Net framework to some extent. You also have to learn the deployment process. VS solutions often need to be deployed as assemblies to the GAC. You should also have a separate development machine because VS requires a SharePoint environment on the same machine in order to reference the SP library. I use the free VM Player. I also have a subscription to MSDN, which is a huge plus ($$$).

If you are not a .Net programmer (particulalry ASP.Net), learning to be one will be your most significant hurdle. If you go this route, I would highly suggest focusing on ASP.Net development training because it more closely resembles the SP environement (web). I would also learn some best practices as early on as possible, such as separation of concerns, using desing patterns/architecture (MVC, MVP, Repository, UnitOfWork, etc). Anyone can write code, but writing good code that is scalable and easy to maintain requires following good programming pratices. Although SP development does not always allow you to implement these patterns, it is good to know them.

Finally, there are a couple "must have" tools for SP development:

• Sharepoint Manager
• WSPBuilder (for VS)
• CAML Viewer

Answer 4

Well, the code can not live in document library to start with. The way SP works is you can have some elements in libraries like master pages, layout pages, web parts etc, but your code is compiled into dll and it either goes to web application root or to the GAC, so, your code will have to be deployed to the server.

Of course depending on your sloution, you may be able to achieve it without custm code.

SharePoint can be customized and it has some out of the box web parts that can be configured and used. This is where SharePoint Designer is used mostly. There are things easier with designer and other things best done in Visual Studio. For example when you are defining CAML based SharePoint feature elements like site templates, list definition schemas or developing web part these can best be done using Visual Studio. But these will require things being deployed to the server.

You may be able to desgn a solution by just using out of the box web parts ans customizing existing SP elements in SharePoint designer, this all depends on your requrements.