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.
Related
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.
I am trying to find out how to host an ISAPI DLL in Azure. In addition to the DLL, I'll need to deploy supporting files in subdirectories (javascript & css files). And two of these subdirectories can have their contents changed by requests handled by the DLL, so I need to ensure that the account executing the extension has write permission for these.
It would seem that the key to all of this is using a startup task to call appcmd to script all the IIS changes somehow, and I think I need to do the following:-
Deploy my ISAPI DLL and supporting files with my ASP.NET website
Create a startup task which will call a batch file utilizing appcmd.exe to do the following:-
Create a dedicated app pool with its managed pipeline mode set to Classic, and using a known user account
Create an IIS application pointing to the directory where my ISAPI dll resides
Ensure the application is configured to allow unknown ISAPI extensions
Alter the permissions of the required subdirectories so the user account associated with the app pool has write access
I've only just started exploring Azure, so my experience with it is very thin on the ground. Is what I'm hoping to achieve actually achievable? And if so, am I on the right track with regards to the steps required? They mimic what I need to do if I'm setting up this ISAPI DLL in the traditional IIS environment I'm used to dealing with, but please let me know if the rules are different with Azure.
Looks like a good sequence, however, the startup tasks actually run before IIS is completely configured. The 'OnStart' event in the RoleEntryPoint is called after IIS is set up, so it's probably easier to use the IIS application that Azure creates for you, and reconfigure it to include your ISAPI stuff.
Well the only thing bothering me here is that you're modifying data on the 'deployment drive' (E: for that matter). You shouldn't be doing this.
Instead, think of an other solution. You could create a LocalResource holding your javascript and CSS files. Then, when your role starts (Richard has a valid point about startup tasks), use ServerManager class to do the following:
Register the ISAPI dll
Add 2 virtual directories under the website created by Azure and point them to the LocalResource.
Modify the code of your ISAPI dll to modify JS/CSS files in the LocalResource
When developing in Web/WorkerRoles, you need to keep in mind that you should only manipulate files in a LocalResource.
I've got a working hello-world like webpart for my SPS3.0
I can compile, pack and deploy it using VS2008, makecab.exe and stsadm. So I know the theory of deploying sharepoint webparts.
My problem:
After I inserted an additional .webpart file, an elements.xml and a feature.xml to deploy the .webpart file and get knowledge about adding features to my webpart, the deployed webpart is missing its safe control entry in the web.config.
But the dll can be found in the gac and my features are also deployed to the right folders.
I didn't change anything in my manifest.xml especially not in it's -tag, because it definitely worked before i added my additional feature files.
Can anybody help me? Should i provide you some code snippets?
Thanks Stefan
You can try WSPBuilder, it will automate and ease your deployment process.
As far as I can tell, you are trying to find out how to register your web part as a safe control without using any tools, etc. and also without admin rights. I think you will find this impossible since the safe control registration needs to happen in the web.config file and one way or another (WSP Builder, manually, script) this file needs to be modified. Only admins can do this as far as I know.
If you are deploying your solution package using stsadm -o deploysolution, be sure that you are either using the allcontenturls parameter or that the url parameter is pointing to the correct web application. Which parameter you use (and how) will determine which web.config file(s) will have the safe control settings from manifest.xml applied to them.
I am looking at the cruisecontrol web dashboard. I can see one farm and one server. However, I don't see any way to add a project?
Is this something I can do with the UI or do I need to edit the config file by hand?
You'll need to edit the ccnet.config file by hand (located within the CruiseControl directory) to add projects. There are some graphical tools to help you do this however you do get used to doing it by hand fairly quickly - just have the documentation near by!
Update: An example of one such tool is http://www.codeplex.com/ccnetconfig
You can use CCNETConfig to edit the config file through an UI although it doesn't support higher version > CruiseControl.NET 1.4.
You have to basically edit the configuration file by hand, however I have it setup so that the raw config file is split into different include files, each of which is setup in my source control system. Then I created a project for the configuration, and then for the whole config. So when something changes in the config, CC.NET itself pulls out the changes, recreates it's config files and the refreshes the system configuration.
This means that anyone can edit the config (if they can access the files in sourcecontrol), and no-one has to go into the program files directory of the CC.NET machine itself.
Not sure whether this answers the question you asked, but this is how our setup works
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