What files can we modify so that our solution is still supported by Microsoft?
Is it allowed to customize error pages?
Can we modify the web.config files to use custom HTTPHandlers?
You can certainly edit the web.config file for your sites. The one thing that you should be aware of, however, is that when you start editing files manually on the file system, you will have to remember to manually make those changes across all servers in the farm (assuming a farm exists). In addition to this, when you edit files in the 12 hive, it's important to understand that you will be making a change to all SharePoint sites hosted on the server(s) for which the files were edited.
Personally, if I were going to create a custom error page, I would simply add a <customErrors> section to my web.config. I avoid editing any existing files in the 12 hive, but I have added files (though it's rare).
The customization of the error page is not very easy (or flexible). You can see an example here:
http://blogs.msdn.com/jingmeili/archive/2007/04/08/how-to-create-your-own-custom-404-error-page-and-handle-redirect-in-sharepoint-2007-moss.aspx
The web.config can be changed. I used my own HttpModules in addition to the original ones, but I haven't used custom HttpHandlers. IMO it should work if you don't change the original handler (i.e. if you add your handler for a specific type of file not handled by SP).
do not modify any pre-installed files in the 12 hive (Program Files\Common Files\Microsoft Shared\Web Server Extensions\12)... a service pack may update and overwrite any changes.
Anything in the Content Database (Masterpage, Stylesheets list in ~Catalogs) is available to modify (I would add, instead of update, in case a service pack changes anything) as it sits atop the file system, and is instantly available to any members of the web farm (newly added servers).
Any custom features, added to the 12 hive in the features folder, in a custom/non-microsoft folder (that is, inside the 12\feature folder, do not modify any preinstalled files, but feel free to add a folder for your feature and work within).
Custom features can be developed using the Visual Studio Extensions (VSeWSS), currently available for Visual Studio 2005/2008... benefit being that the output is a feature package (.WSP file) which is designed to be portable across SharePoint. Additionally, the .WSP files are just CAB files with a different extension, offering the ability to be explored by simply renaming them.
For site definitions, Microsoft has a good article about what is supported and unsupported. In short, the only change you can make to the out-of-the-box site definitions is changing the entry in the webtemp.xml file to hidden in order to prevent the site definition from appearing in the site template list. This is something many may be interested in doing.
You may also, of course, copy existing definitions and rename them in order to create new ones.
The complete list of supported and unsupported scenarios for working with custom site definitions can be found here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;898631
Here is the closest I can find to a official response from Microsoft:
http://technet.microsoft.com/en-us/library/cc263010.aspx
Related
It's very straightforward to add languages to an installshield project. My goal is to
make a modified English (0x0409.ini) with some of the strings modified, such as
However I have a team of people that would have to copy these files to a directory much like C:\Program Files (x86)\InstallShield\2012Spring\Support andC:\Program Files (x86)\InstallShield\2012Spring\redist\. This is even worse with the 10+ machines in the build farm that could potentially need this file. It's a non-starter. It's hacky to have modify the install of a tool to get it to use an unsupported language.
Is it possible to check the language file to SCM and have it reside in a subfolder of <ISProjectDir>?
I don't believe so. I think you'd have to set up a post-build step that would copy in a modified ini file.
You could set up one in installshield's UI but I don't know if that persists in a stand alone build.
Background
I work in QA at a software company.
We have about a half a dozen different web applications, each of which may require, at any given site, some customised settings added to its web.config file.
These can range from which Oracle database/schema(s) the app connects to, to how many search results to cache, to which hierarchy to use when sorting items on a web page.
We make use of Microsoft's Deploy package, to get the new releases installed/updated on client sites.
When we put out a new release, some of these customised settings may have been added to or removed from the given web app's web.config file, but using Deploy to import the new release over the top of the old one will clobber any customisations that may have been made.
Alternatives
There are ways of handling this manually, such as merging via a plain text comparison of the old and new web.config files, but these are cumbersome and prone to human error.
I was reading about transformations and thought they could be of some use.
There is also the capability to use external files (tip #8) which seems like a good way to go.
Improvement?
Should our programmers be providing some sort of semi-automated merge facility for this web.config file? Does the Deploy package provide this somehow?
Should we be making use of the external config files, as a best practice?
Is the concept of customising this web.config file at each site so fundamentally flawed that the whole thing needs to be re-thought?
Microsoft provides Web.config transformations as the de-facto way to do this. You can create different deployment configurations within Visual Studio and the web projects. Then when you build or your build server builds with that particular configuration the web.config is transformed to contain the settings you want to see.
View more about web.config transforms here.
Had started my typical EE build (using a bootstrapped config) for a client when they announced they wanted another additional site using the MSM module (le sigh).
So added the MSM module, I commented out the $config['site_url'] and $config['cp_url'] and set those in index.php instead using $assign_to_config.
That's when I discovered this bug where MSM config file settings are not recognized, which is a pain but I can work around it. However, I noticed that when I created the secondary site, it wouldn't recognise my custom location for add-ons and so I had to add that to index.php as well to $assign_to_config['third_party_path'] = "../assets/third_party/";.
Then I discovered that when I create or modify a template file, it won't automatically sync and so I need to manually do that each time which is a real PITA.
Why would my templates not be syncing to the database? Is this related to the MSM config bug?
While I haven't tried bootstrapping the third party path yet, I've definitely been able to bootstrap the template path for MSM sites... What bootstrap method are you using?
Are your sites on subdomains or subfolders? I've only had experience with subfolders so perhaps that makes a difference (although it shouldn't).
Could you maybe walk through in a bit more detail what's happening? Your first site (site_id = 1) templates sync automatically from filesystem edits, but your second site does not? Yet if you go to CP > Design > Synchronize Templates, that works?
The $assign_to_config portion of MSM setup is definitely a weakspot when it comes to bootstrapping... I wonder if we need to work up an additional bootstrap for MSM+CP environment, where it looks at the cp cookie ($_COOKIE['exp_cp_last_site_id']), and sets values based on that.
It may be helpful if you let us know which bootstrap you are using. For example, if you look at this bootstrap the site_url and cp_url are set using the HTTP_HOST server variable, so this shouldn't clash with your MSM install (and multiple domains) at all.
Perhaps you could try using that boostrap file instead, and see if it fixes your issue with template syncing?
Finally, if you're going to use the EE template manager, you don't really need to store templates as files. Conversely, if you want to save templates as files, it's probably much easier editing them using Sublime Text or another editor, rather than the clunky built-in editor (which is really only useful for small/simple changes).
I use NLog for logging and now I'm trying to also use it for my SharePoint solution.
How do I instruct WSPBuilder to include NLog.config in WSP and place it in the same folder as solution dll?
EDIT:
Okay, another option is to put it as Web.nlog in SharePoint 80 directory.
Do I need a separate feature for this? What should I write in elements.xml?
I don't think this can't be done - I assume for security reasons.
DLLs can only be deployed to GAC (signed assemblies only) or to the bin directory of the web application (deployed via the solution manifest, along with any required CAS policies).
If you want extra files alongside the assembly in the bin directory, you'll need to copy them manually.
Does NLog.config need to be a separate file, or can the settings be integrated into the web.config file? If you can integrate the settings into the web.config file, you can add a feature receiver and write the necessary settings during the FeatureActivated or FeatureInstalling event to web.config using SPWebConfigModifications (just google for it). You should also make sure to remove the settings in FeatureDeactivating or FeatureUninstalled event.
You should also take a look here :
http://msdn.microsoft.com/en-us/library/ee413935.aspx
I would also ask these questions :
Is the configuration the same for all the farm ? Only one web application ?
Can you programmaticaly specify NLog configuration ?
Depending on your answers, I will suggest one or more solutions.
The disadvantages with the web.config are
Configuration is deployed on all SharePoint servers (the feature take care of that, but you have to keep that in mind in case of inconsistant behavior)
If you want to modify settings there is no easy way
Each time you modify settings, it will recycle application pool.
I recently upgraded my SharePoint development machine to VSeWSS 1.3 and have noticed a behavior that I didn't think existed before. I have two custom web parts that use several common assemblies, and both will live in the same site. I'm trying to create a third 'common' web part that copies these files to the Bin folder and adds safe control entries to web.config so I can remove one of the web part solutions, if needed, without crippling the other one.
With the prior version of VSeWSS I thought it only included assemblies in the manifest if you included them in the given Visual Studio project. I've removed the common assemblies from the two web part projects, but entries for them still end up in their solution manifests. Obviously the extensions are looking at the references for the web part and going by that, even if the file are in another directory alltogether.
Is there any way to tell the extensions to not add assembly entries to the manifest even if they are referenced in the project? Or is there a better way to separate the common code from the web parts that use it?
Yes you could prevent VSeWSS from deploying assemblies. Just select the assembly in the list of referenced assemblies in you VS project and look at its properties. There you can find the option "LocalCopy", which you have set to false to prevent the assembly from being deployed.