The question is entirely described in the title: is it possible to have multiple components in the same .NET assembly. All examples I've seen so far had a single custom pipeline component per assembly.
Microsoft.BizTalk.Pipeline.Components.dll would be a good example.
Thank you.
Sean, are you asking if it is possible to have more then one custom pipeline per assembly? If so then yes. Whether or not it is a good idea is more organizational then anything.
Personally we generally decide by our deployment needs or desires. Do we want to be able to deploy the pipelines piecemeal or by a certain customer where multiple pipelines makes sense.
The answer is Yes. As long as each component coded and deployed properly, they all show up in VS.NET designer and are usable.
Related
As the title says...
I've successfully got workflows working that create project tasks, so I have some idea how the workflow customization tools work. But I'm struggling to see how I can (or even if I can) use a workflow to auto-magically add resources to the project (and then assign them to the project tasks I dynamically create.
Regarding which users/employees to add as resources, I imagine sorting out an appropriate clause shouldn't be too hard.
If I recall correctly, Resouces on a Project record are sublists. If I am correct, then it is not possible via workflows. There is a limitation with Workflows that they cannot work on record sublists.
You will have to do this via SuiteScript.
I'm working on a Sharepoint 2010 project that has quite a few visual webparts.
Currently I have all web parts in the same solution. My colleague is working on the same project, but is creating a project for each web part inside the solution.
What's the best practice here? What are the advantages/disadvantages of each approach?
thanks.
I tested both approaches when I started developing Sharepoint solutions and I conclude the following Pros / Cons:
Pros of having separate project for every webpart:
much faster deployment and testing of your code changes <- you don't have to deploy all the webparts everytime you make a single change.
easier and better team collaboration <- usually every developer works on a single webpart this way, everyone's code is separated and there won't be checkin/checkout conflicts.
better code reusability, if you needed at any time in the future to use a single webpart in another project you will find it much easier to just go and get the webpart project.
All webpart resources in a single place, usually the webpart uses some resources (resx / images) which you can include in it's project, imagine having a big solution and all the resources of all webparts are spread around in a single project, it's much harder to just get your webpart to use it in another future project because you have to find all related resources.
I hope that's enough to let you enjoy the Webpart per project appreach.
All in one project unless there's a good reason to break them out (i.e. they need to be delivered separately).
It is about deployment. A single project results in a single wsp file, so if you want to deploy all web parts together, stick to the single project. Otherwise, split them up as appropriate.
If its a big project, a seperate project for each webpart could be an overkill. Unless there is a good reason (such as deployment), all should be in same project.
We are currently in the process of drawing up a solution for an existing client, creating a number of eServices. The client currently have MOSS 2007. The proposed solution is to use MOSS as the launching pad for the eServices…
The requirement involves drawing up several online forms which provide registration facilities as well as facilitating a workflow of some sort. I have been told that the proposed solution requires complex web forms.
Most are complex forms with parent child details that have multiple windows. The proposed solution is to do some bespoke development, developing ASP .NET forms. These forms would be deployed under the _layouts folder of the current MOSS portal, inheriting the master page design on the current site.
I have been told that this approach make development and deployment more simple, as well has having ‘complete integration’ with MOSS.
My questions are:
Is this the best way to leverage SharePoint – it seems like the proposed solution is not leveraging MOSS at all..! I thought perhaps utilizing Web Parts would be better, but I have been told that this is more complex and developing more smarter intuitive UI is more difficult. Is this really the case? If not, what should be the recommended approach?
We will be utilizing Ultimus as the workflow engine. However, I have been recommended K2 Workflows. Anyone used both/have any opinions on either?
Many thanks in advance!
Kind Regards,
If they have MOSS 2007 Enterprise, you might consider if web rendered InfoPath forms can meet your needs for "complex web forms". When it comes down to it, probably all of these technologies can meet the neeed it is just a matter of what skill sets you and your customer have and how that will facilitate keeping this solution up to date.
Asim, what they propose is a possible solution. They can however provide the same functionality by making use of webparts. With the details you are giving us that isn't really possible to decide which option would be easier. I used both approaches in the same project depending on the requirements of each functionality.
I can understand that it doesn't seem like they are leveraging MOSS, but they actually are building pages within the context of MOSS.
I haven't really heard about Ultimus, I did use K2 in a proof of concept and I was quite happy with it. Then again, choosing the right workflow solution depends on your requirements.
What would make development with SharePoint easier?
A better product.
Right now it is to many things that doesn't behave as a development environment should.
Dispose of objects
Performance of traversing small lists with 3000/4000 items
Lack of support of transactions
Hopefully next version will have the SQLServer based lists where you can have transactional support and better performance......
Bill G raised the question in feb 2008 that it is something strange with Sharepoint that you get problems when you have 3000 items in a list and SQL Server easily supports million of items....
The build and deployment process needs to be simplified. There are numerous tools available to create WSP files, but they are all decent at one thing another, but you ultimately need to extend or rework the solution WSP deployment package for you environment.
Standard HTML and better support for the DOM.
Informative error messages.
While easier debugging and less XML are very tempting (as people suggested), I would settle for something much more modest.
SharePoint usually "swallows" exceptions or other error messages. Very often when a customized page or a web part fails, you get an obscure 'page cannot be displayed' message. With luck, the designer will direct you to the problem, or you might find some details on the logs or the system event viewer. But in many cases you have nothing.
Examples - Business data catalog xml monstrosity that worked on the editor but not on the site, xml web parts that fail randomly, xsl typos or mistakes, etc. All take much longer to find than they should, and some are impossible to debug.
Remote Deployment:
- 1 central Sharepoint, and transparent remote debugging.
Less XML (schema.xml etc).
Making the dev process more like "traditional" asp.net development, in other words making the integration with VS better. You should develop against SharePoint from within VS not from within SharePoint (ie SPD).
SPVisualDev on codeplex has made that process better but I hope (an I say hope) for better support within VS2010 together with SP2010.
Should check out #SPDevWiki's page on this also http://www.sharepointdevwiki.com/pages/viewpage.action?pageId=7340352
Less people trying to abuse the product would make things a lot easier too ;)
I am total beginner in SharePoint and I need some help in starting a project. I have to develop publishing site that will be delivered to the client. I would like to give client deployment experience like he would get when deploying standard ASP.NET application as much as possible. I plan to use Visual Studio 2008 with SharePoint extensions and maybe WSPBuilder or some other tools.
I also need help in structuring whole project.
Here is what I plan to do:
1. Develop minimal site definition
2. Create site from this defionition. How should I do this from code ? Use SharePoint Feature ? How should I activate it ?
3. Develop all the needed infrastructure for the site (master page, layouts, content types, ...) as SharePoint Features.
Is this correct and how should I develop all those parts so I can make a some kind install script so can client create get complete site with one click ?
Site definitions are complex no question about it, but they are very useful if you need to deploy to unrelated enviornments. If you are staying on the same server farm, maybe site definition is overkill. If you are going between domains (i.e. test & prod, then maybe they are worth looking into).
Another advantage to site definitions, esp. if delivering to a client is it feels more like a traditional deliverable. They will have a bunch of files (hopefully in source control) that are their custom site. I think that gives IT dept's a much warmer feeling than an XML file created from the SharePoint UI.
Another benefit of site definitions are you have a lot more control over the pages that make up the site. IMHO its easier to add master pages & custom CSS via site defintion that site template.
I am curious as to what are the 'moving parts' to the site you are trying to deliver? I think that answering that question will determine how to define the project's structure.
Generally, I think you are on the right track. Features and solutions are a must. I would stay away from VSeWSS, its buggy and clunky and generally terrible if you are trying to do anything complex. It tries to be so smart, that it leaves you no control.
That said, it really depends on what you are trying to do. If you are going to build a solution to deploy to the GAC with one assembly, and only building features supported by vsewss you may be fine.
If however, you want to develop, say a timer job wiring that into the VSeWSS feature framework gets tough. Also, if you need multiple assemblies in the solution. YMMV, but I had to junk it and find of a more flexible solution (hello NANT).
A lot of the work you will end up doing is building and checking, and re-checking XML configuration files. Bookmark the Feature Schema reference page on MSDN, you will be spending a lot of time going through it.
Finally, yes, if you have all of the parts packaged as features you should be able to develop a nice install script. Ultimately the script will need to call the STSADM (there are some really nice STSADM extensions here) commands necessary to create the site structure, add & deploy the solution & activate the features. You can start with a batch file, and get as complicated as you want.
Personally I don't find that creating a site definition is really that useful for the sites I have built. They can be very tricky to set up, because of their complex nature.
What I do is use the standard Publishing Site and then using features to add my additional componets (deployed via a SharePoint solution).
You can use Feature Stapling to connect up the feature to the Publishing Site creation.
I've also just done a blog post on how to programmatically modify the workflow which is created by default: http://www.aaron-powell.com/blog/february-2009/programmatically-modifying-sharepoint-workflows.aspx (that also has a link in the comments off to the Feature Stapling concept).
Then I use a combination of SharePoint Solution Installer (http://www.codeplex.com/sharepointinstaller) and batch files to install the components. SSI for all the SharePoint database level installs and batch files for the file system stuff.
Adding another answer, because I have more than 300 characters worth of stuff to say :(
RE: SharePoint solutions generator, again I would say your mileage may vary.
The biggest issue with SharePoint dev is managing all of the "magic strings" across the various configuration files. GUIDs and Fully Qualified Assembly names are the spit and glue that hold the whole thing together, and although it all makes sense its very difficult to manage.
The current crop of tool all try and alleviate the complexity of managing these things, but they require that you work in a certain way, so the tool knows how to inject the appropriate plumbing.
If you plan on doing a lot of work with SharePoint it really behooves you too learn to manage the plumbing yourself. Its painful up front, but really pays dividends.
Basically, I suggest you spend your time learning the platform and not the tools. Once you know the platform, using the tools will be much easier.
If you are doing this as a one-off engagement and just want to get it done, I'm sure you can get any of the tools you've mentioned to do the trick.
I would agree with the use of the out of the box publishing site definition, and then customizing it using Site Collection features (Master Page, Page Layouts, CSS) and site features (create lists, pages, sub sites, defining master pages of sites, etc...).
Feature stapling is great when you want to customize new sites (allow user to create new sites) of well known site templates, like customize the "My Site" look and feel. In this case I don’t think its very useful.
As a tool to help this task, I personally use STSDEV (http://www.codeplex.com/stsdev) to help in creating, programming, debugging and deploying my Sharepoint solutions.
First it creates a good project for Visual Studio (clean, or with some nice "starting point" definitions). Then it includes some “build configurations” that really helps with install, deploy and upgrade in the development machine.