For a team of 3 developers in an Acumatica project which uses the Acumatica Extensibility Framework (AEF) quite heavily, we are using Git as a source control. However, I am still not sure what strategy should we follow regarding creation of Customization Projects. Should we just use 1 Customization Project to be shared across all developers or should we divide Customization Projects per feature (or possibly per developer)? What are the implications of each approach? Is there any guidance by Acumatica on this matter?
We do a single customization project as we are working on a single product (multiple modules). Distributing the customization makes it easier as a single zip file vs many zip files. We use a powershel script to create the customization package outside of Acumatica which simply stitches all of the files into a newly created zip file. This way each developer can quickly make a customization package and load the latest as needed (again pointing to a single package as our preferred approach). Hope this helps.
Related
As I'm in development on my 2nd and 3rd kentico sites, we're looking at code management. Our ideal solution is a single Kentico Solution, with individual CMS folders.
In theory this should be fine, but would there be any potential issues, especially regarding versioning? Right now, I have one site on 9 hotfix 5, and the other two on 9 hotfix 30.
There would be a problem with applying hotfixes and upgrades. They both count on the fact that the web project is in a folder called CMS... So you would introduce some manual steps in those processes. Conclusion - don't do that.
I certainly agree with #rocky. I'd question what advantages you expect from this scenario? I assume the 3 sites are entirely independent of each other (don't share a database) so keep them as separate Kentico solutions. They're separate applications so why share a solution file? This'll make your life so much easier. A solution should only contain multiple applications if they're intrinsically linked.
If it's because you have custom code that you'd like to share between the instances, best to move that code into custom assemblies and share those in your various solutions. If necessary your separate solutions could include the same files as per this folder structure overview below. This way your hotfixes and upgrades remain entirely localised and you remain safe from harm!
Development
Kentico 1
CMSApp.sln
CMS
CMSApp_AppCode.csproj
References My.CustomBusinessLogic and My.SharedCore
Kentico 2
CMSApp.sln
CMS
CMSApp_AppCode.csproj
References My.SharedCore only
Kentico 3
CMSApp.sln
CMS
CMSApp_AppCode.csproj
My.CustomBusinessLogic
My.CustomBusinessLogic.csp
My.SharedCore
My.SharedCore.csproj
From a development standpoint you should be fine. When performing upgrades, hotfixes or new installs this may cause problems because the KIT looks at the actual .sln file or the actual root directory the .sln file is in.
What I would do is setup a solution like this and try out an upgrade and a hotfix and some local development.
I am starting to do a lot of sharepoint development lately, and some of the things that I have done and I dont like is to use sharepoint designer directly for things like pagelayouts, lists definitions, master pages, etc.
From my point of view I think its more organized to do everything in Visual Studio. In that way you can connect each solution to a source control database and deploy/retract/upgrade easier with scripts.
My idea is to create a vs solution like this:
1. One for list and content type defintions.
2. One for webparts.
3. One for branding
but maybe this approach has any disadvantage, what other approaches are you using?
The real answer is going to be: it depends.
I do not think there is one best way to organize a Visual Studio solution or SharePoint solution packages. In the end, you need to find what works best for your organization and go with that.
The only guidance I have seen is from the SharePoint Online documentation:
If the development team is designing a solution that requires more than 10 WSP files, the team should reconsider its architecture. It is difficult to manage and deploy so many WSP files within a single deployment window, and the solution risks rejection because of the complexity for SharePoint Online of managing it.
A large number of solution packages (WSP files) that need to be tracked and managed pose a challenge for deployment. The more solution packages in a customization, the greater the possibility that something will not be installed correctly, the longer the solution will take to deploy, and the easier it is to mix incompatible versions of solution packages. We recommend that customers scrutinize their deployment plans and keep the number of solution packages to the minimum number needed for the project. Keep in mind that a solution package can contain several features, so there is no necessity to have one solution package for each feature.
And I would agree with this. You seem to be outlining 3 Visual Studio solutions and/or SharePoint solution packages for what really are 3 Features within a single SharePoint solution package.
I tend to create one Visual Studio solution for each project. For a very large project, that single Visual Studio solution might contain several projects where each represents a SharePoint solution package.
For Farm solutions, each SharePoint solution package will contain a number of Features and files that are all related in terms of functionality or application. If two or more SharePoint solution packages share common Features, I will put those shared Features into a separate solution package.
Sandbox solutions tend to be much smaller than Farm solutions. While my Farm solutions usually represent an application, my Sandbox solutions are more focused to solve one particular issue. So my Sandbox solutions usually only contain one Feature that does not rely on other custom Features or solutions.
As I said in the beginning, I do not believe there is one hard or fast rule. It is usually determined by the preferences and style of a particular development team. Try a couple different ways in the beginning and eventually you will find what fits your team best.
I have created and deployed a MOSS Site defintion using VseWSS 1.3
I install the site definition and create a new site and everything works fine. However, when anybody goes into any site on that WebApplication (in any site collection) and goes to the feature list then all these features are in the list.
I have about 15 content types, with 15 lists based on these content types each with their own instance and ItemRecievers. As you can imagine this is a lot of features in the list. My Sharepoint administrator saw this and had a meltdown...
He wants to see a single entry like you see for the MOSS Enterprise features etc, that activates all the features for my solutions. I have seen somebody menation the term 'feature pack' - in relation to this but I don't know if that's just their terminology.
How can I do this? Can this easily be done is VseWSS or do I have to go in manually and hack the IDE generated files?
james :-)
VseWSS isn't great for producing solutions - it can pull out elements of a solution, but tends to (in my limited experience with it) set things up like they're all going to be seperate features.
The unfortunate thing is, your Admin is right. What you've got - those content types, list definitions, and list instances - are a lot of feature Elements. A single Feature can have many of those, usually in a file called 'elements.xml'. There's a good description of this at:
http://msdn.microsoft.com/en-us/library/ms460318(v=office.12).aspx
(Note, in Visual Studio 2010 parlance, these elements are 'SharePoint Items' within the visual studio project. But I digress)
I've always tended to use VseWSS to create the files that I need - my list definitions, etc. - and then copy these files into a WSPBuilder project for packaging, ready for installation. If you've not used WSPBuilder, I recommend it for SP2007 development - though it's largely superceded by Visual Studio's own tools for SP2010. It takes a little understanding, but then you'll realise that if you simply copy the files into the right places, you can easily build your solution.
(You should be deploying your solution in a WSP file. ALWAYS deploy solutions in WSP files.)
(Also, you shouldn't have to 'hack' any of the files, just rearrange them on the file system so WSPBuilder packages them correctly. See the WSPbuilder documentation.)
An easy option to do is simply modify the feature elements to hidden, and create your primary feature as a visible feature with activation dependencies. This means that once the primary feature is activated all the dependency features will be activated automagically.
http://blogs.msdn.com/b/jjameson/archive/2007/03/22/scope-dependencies-for-sharepoint-features.aspx
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.
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.