We have a product which is developed using SharePoint foundation 2010. We are hosting on port 80 and which was stand alone installation of the MSF 2010. Now i need to deploy the same product on different ports for different clients in the farm environment.Right now i am facing some challenges as follows:
we have css, images, jquery files which are mapped to 14 hive folders. Since we were deploying in standalone environment, entire 14 hive folders were serving for one client. Now challenge is, how to manage these css, jquery, images folders in 14 hive folder for different clients(different web applications). If i do small change in one js file(test.js) for one particular file, it should affect for that client itself. It should not affect on other client's js(test.js) file.
Since we are having only one wsp solution, and we need to add this to solution repository. Since sharepoint allows only solutions whose names and GUID are unique. So, if i do some change in one solution for particular client , when i upload it to solution repository , it will not allow, since old wsp is already existing. So, how to manage wsp to serve for multiple clients ? . if i do changes for one client, it should not affect on other clients.
please let me know the best practice for this.
Given that a feature can be activated and deactivated at a SPSite or SPWeb level, there could be a more elegant solution to this situation.
Instead of packaging your images, CSS and JS files to be deployed to the 14 Hive, you could actually have them deploy to a new Document Library that your feature creates in the SPSite/SPWeb when your feature is activated. You can also configure your WSP such that the JS, CSS and Image files get uploaded to the document library so created.
This way one of your problems is solved wherein you can modify the files for one client manually directly through the document library and it won't affect other websites/clients.
Also, in this configuration, your single WSP will be sufficient and should not conflict since you won't be deploying a whole new WSP when you change some code for just one client.
I found this blogpost that shows you how to achieve the above: http://jcapka.blogspot.com/2011/05/deploying-document-library-including.html
I also would recommend this series to know more about different options of packaging things to your WSP: http://blogit.create.pt/blogs/andrevala/archive/2007/12/02/SharePoint-2007-Deployment_3A00_-Overview.aspx
Its written for SharePoint 2007 but most of it hasn't changed in 2010.
If there are any challenges in the above approach, you can probably find workarounds for it.
When you deploy solutions to SharePoint 2010, they are generally packaged as WSP, which are generally named as business area.
If you are using Visual Studio, Open "View -> Other Windows -> Package Explorer" to explore contents of WSP.
So if your clients have different html, css, javascript, consider packaging them in different WSPs.
One solution per client
This way under 14 hive, each solution (WSP) items will be contained in their respective folders, which means changes in css of one solution won't affect other solutions.
If you have application pages, they can go:
14\TEMPLATE\LAYOUTS\Client_1\
14\TEMPLATE\LAYOUTS\Client_1\css
14\TEMPLATE\LAYOUTS\Client_1\javascript
14\TEMPLATE\LAYOUTS\Client_2\
14\TEMPLATE\LAYOUTS\Client_2\css
14\TEMPLATE\LAYOUTS\Client_2\javascript
14\TEMPLATE\LAYOUTS\Client_3\
14\TEMPLATE\LAYOUTS\Client_3\css
14\TEMPLATE\LAYOUTS\Client_3\javascript
If you have client specific webparts, they can go:
14\TEMPLATE\CONTROLTEMPLATES\Client_1\Webpart1
14\TEMPLATE\CONTROLTEMPLATES\Client_2\Webpart1
14\TEMPLATE\CONTROLTEMPLATES\Client_3\Webpart1
All you need is to create well defined directory structure in your WSPs.
Related
We have an ASP.NET website that we want to deploy (and remove) multiple instances of the site on the same IIS machine.
We also have a few number of customers that need to install the product on their system.
I was hoping WIX would be able to handle this, but it appears you can only have one instance installed at a time.
What options are available to me? Right now we use FinalBuilder to setup a generic "install package" which uses a batch file that a user populated with their environment settings, and uses tools like sed and awk to update config files and more scripts to deploy to IIS.
It works, but it's very cumbersome. I was hoping to find more of a GUI/command line interface to replace this process.
It sounds like MSDeploy will work for your use case. It can deploy multiple instances to the same IIS instance and can also delete instances.
The following post is specifically about service versioning but you could use the same technique to install several instances of a web app.
http://www.dotnetcatch.com/2016/03/03/simple-service-versioning-with-webdeploy/
What is the best practice approach to local user generated content when using Microsoft WebDeploy and Team City to deploy fixes to a site?
Using the deployment process described by Troy Hunt:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html
When changes are made to a site the WebDeploy agent updates the site including removing old files that are no longer needed - which is great. However in the case where a site contains user generated data (say users can upload an image which is stored as a file on disk or a simple CMS where page content files can be updated by the user), what is the best practice to prevent these files being deleted by the deployment agent?
Is there an ignore flag for certain folders?
Should the user files be stored outside the root of the deployed website (Is this a security risk)?
You basically need to use MSDeploy's skip rules. This will tell MSDeploy to ignore certain files, folder, or subfolders etc.
It depends on where you implement these to what the syntax will look like. But you have the following options:
If your publishing through VS.Net using a publishing profile you can include skip rules here (I've taken this approach and seen it work fine). This SO question should point you in the right direction - MSDeploy skip rules when using MSBuild PublishProfile with Visual Studio 2012
If your using a vs.net web solution (website / web application) I later found out you can also implement skip rules in the web.config. Although the following article is a bit old the approach may still be viable - How to write skip and replace rules for MSDeploy (I havent used, or tested this approach)
Last, but not least, you could use MSDeploy skip rule on the command line itself. So assuming you execute msdeply directly (as opposed to via msbuild) you would need to append a skip parameter with the relevant attributes you require. Further information can be found at: Demystifying MSDeploy skip rules or Web Deploy Operation Settings (Look for the skip command reference, about 2/3 down the page) (Using publishing profiles with MSBuild ultimately makes this call for you, i've seen it in action working by using the first approach above).
Hope that helps!
I've got a DotNetNuke system (v 5.6) that's hosting several different portals, and I'd like to move one of them to another hosting provider. What's the easiest way to do this?
Every web site I find that claims to explain how to move a DotNetNuke site essentially says "Copy the entire database over to the new system." That's great if you've only got one portal in the database, but I've got a dozen of them. I only want to move one portal, not all of them.
Exporting the site to a .template is another popular suggestion. This exports the structure of the site (all the tab definitions, for example), but it doesn't include any of the actual HTML content. As such, that's essentially worthless.
There must be a reasonable way to do this short of trying to strip one individual portals data out of every single DNN table. Right?
When you export a site template, you can include the content of the site, as well (for the modules that support portability, which includes the standard HTML module). This is how the default site template has all of its content. When you do this, there will be a .template.resources file that you'll need, as well as the .template file.
The other option is to do a full backup and restore, and then remove the other sites once you've restored. If you have significant content in a module that doesn't support portability, I think this will be your best bet.
FYI, I did find a solution from someone over on the DotNetNuke forums.
Create a 2nd version of that install, then delete all the other
portals. Move the install with the one portal. We've done this several
times with installs with lots of portals and it works just fine. Yeah
there's still some noise left in the db, but it's a quick and
effective way of doing things.
Edit note that this will give you an install with 1 portal. You can't detach a portal from one install and reattach it to an existing
install (well, you can, but basically you have to export the portal as
a template and that isn't 100%)
This is the approach I took, and sure enough, it works.
In a nutshell:
Mirror the files for the web site to another server.
Mirror the DNN database to another server.
Log in a Host on the new setup and delete all the portals but the one you want to migrate.
Delete any module definitions that are not in use by the remaining portal.
Open up your favorite SQL tool and delete any entries in the Users and UserProfile tables that no longer have a matching row in the UserPortals table. DNN does not remove these by default, which is frustrating.
Hop in to Windows Explorer and delete all of the Portal folders you no longer need (ie: /Portal/1, /Portal/2, etc.)
Back up the database using Enterprise Manager to create a .bak file
Make a .zip of the entire DNN installation folder.
You now have a .bak that contains the database and a .zip that contains the files. Send those off to the new hosting company, and you should be all set. Just make sure to update your web.config to set the connection string properly to point to the new database server at the new hosting company.
It's just that easy. ;)
I'm sorry for such a complex subject. My problem is.
I tried to move my Drupal 7 site from one server to another.
I uploaded a fresh install to my new site.
I backed up my old database and imported to my new site.
I uploaded settings.php file to my new site.
When i entered to my new site's module part, All the 3rd party modules i installed in my old site, exist in my new site without any loss :)
But when i check the folders
/sites/all/modules
/sites/default
/modules
I couldn't find any file regarding to this modules.
Modules exist in my new site when i check my admin panel, I can create content by using this modules, But i can't see their files by using file manager etc.
Thank you
Because you didn't disable the modules before moving your deployment, I think they're still marked in your database, same for registration of content types. As the modules don't actually exist, you won't get their functionality.
Replacing the modules under /sites/all/modules or /sites/default/modules should leave them working as before.
What is the purpose of datasync project in weblogic project?
What is *.evt, *.req, *.usr files?
There is a good explanation on the docs about datasync. Basically it is a webapp used to copy data across from one weblogic server instance (actually from it's database) to another. Example - copying all the data from production to test instances.
*.evt, *.req, *.usr files are XML format files used in Weblogic Portal applications.
EVT files are event files which can be triggered at any user interaction with the Portal. This is mainly used for capturing user behaviour and firing any rules, an example is a
campaign fired for specific users.
REQ files define the HttpRequest attributes
USR files define UserProfile attributes