I need to create several WIX installers that references another project in a different solution (i am using visual studio). For sake of ease lets call this "solution X". All my wix installers are in different solutions from each other but they all share this common project which needs to be referenced. Is this possible?
When I create my wix installer it only allows me to reference projects in the same solution.
I cant just copy the project over to my solution because solution X is constantly being upgraded and that would mean we would need to edit the code in many different places.
My company aka the business has decided all the wix projects must be seperated because they reference other specific projects also.
Whats the best way to approach this...
Related
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.
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.
We have a very large solution project for our MVC structure where I work. I am trying to filter my solution explorer down to only relevant files with a custom filter. Microsoft has an article on making a custom filter here, but when I try to build the source code they give it says one of the .NET Framework namespaces is not available (I have already reinstalled .NET). The namespace that won't resolve is: System.ComponentModel.Composition. I am hoping fixing this will allow me correctly build a filter (there are 5 errors in the project total).
I definitely have the 2012 SDK installed (you won't make it far in the tutorial without it).
The Funnel extension may be what you're looking for:
Decrease solution loading and re-compilation times dramatically by filtering projects not relevant for the current task.
The extension loads just the projects defined in filters (load filters must be defined before using them).
You've to add reference to "System.ComponentModel.Composition" assembly. This reference is in framework 4.0.
If you've problem referencing or finding this assembly, refer to this answer:
https://stackoverflow.com/a/6310236/2617201
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