I have a scenario where I am asking consultants to deploy 2 applications. A console application and an IIS web service application. Both apps form part of the solution.
I haven't created an easy to use installer, but was wondering if there is an open source config editor that I can ship with my app that can read in "only certain" values and allow the consultant to change these values.
This would be much less hassle than asking the consultant to open up web.config or app.config - because the configuration is pretty complex for a non technical person, and they're overwhelmed by all the XML.
I guess as a programming question, this would be a question relating to deployment.
What exactly are the sections which you want the developers to read ? I would refer you to this question Can a web.config read from an external xml file?. You can keep part of your web/app.configs externally and read from them.
more reference:http://blog.andreloker.de/post/2008/06/Keep-your-config-clean-with-external-config-files.aspx
Related
Does anyone know how you version / source control changes in Reddot Cms (OpenText). Also is there any best practice advice for release management of changes from one Reddot environment to another Reddot instance. Any help or advice would be greatly appreciated.
There is best-practice, but as you have probably realised, there aren't too many practitioners of RedDot these days. In case you should come back to this thread (or for someone else's benefit) Versioning is built into the Template Manager, but has to be enabled. There's no Source Control integration last time I checked, but we developed a prototype system that allows for the creation of templates in Visual Studio. The project to complete that has since died due to lack of commercial support, but some of the ideas may be useful for you if you want it.
I split up the answer in two parts: Versioning and migration between stages.
Versioning can only be done with the template history or via an external service that grabs the templates on a regular basis or triggered manually. At least for the Management Server there is no built-in service for a "real" versioning or release of more than just single templates/content classes or even including pages.
There are 3 ways of moving changes from dev to test or prod I have seen often:
Two templates: Using two templates on one server, on called "Development" and the other one "Production". All new development is done on the "Development" template and moved to the other template as soon as finished. If elements are different between those templates they need to be duplicated. This is typically on small installations without staging areas. Nowadays, you will find only very few of those.
Partial tree export: Development is done on a dev server and the changes are exported as partial tree. There is a special area in the project tree where pages are created which templates shall be moved over. These are exported including the templates and imported on the target server to override the existing ones.
Tool support: There are external tools for moving templates and content classes to other servers. There is e.g. SitePort (http://siteport.net , can also move whole templates between RedDot servers afaik) and the Sync Tool (http://www.erminas.de/en/products#synctool , can compare and move single element attributes and/or single lines of templates, please note: this shall not be advertisement as the tool is made by us but I do not know any other like this). Some companies also have custom development tools for this.
I have a local Sitecore instance where I made changes involving both code and the creation of a new sublayout.
After deploying the code I can see on the new environment the usercontrol (.ascx) file associated to the sublayout, but the corresponding item does not appear and cannot be used.
If I attempt to recreate the usercontrol, it tells me that the file already exists, and due to my lack of experience with the platform I found myself unable to import it.
What would be the optimal way to proceed?
To deploy your new sublayout correctly you should create a Sitecore Package. This is basically a zip file that allows you to move both items and disk files between Sitecore instances in a controlled manner. For basic installs of Sitecore, where you have not added any specialised tools, it is generally the preferred way to move resources between servers.
The "Package Designer Guide" on the Sitecore Developer Network will give you information about how to use the Sitecore UI on your development site to create a package containing both the Item(s) and the file(s) for your sublayout:
http://sdn.sitecore.net/upload/sitecore6/65/package_designer_admin_guide-a4.pdf
Once created, this package can then be imported onto whatever other servers you want to deploy your sublayout to.
-- Edited to add --
Derek Hunziker's answer makes a good point: As well as the basic Sitecore behaviour there are third party tools available which can enhance and extend the deployment experience if you wish. As well as Hedgehog TDS, you might also consider:
The "Sitecore Rocks" extension for Visual Studio allows the creation of packages from within the
Visual Studio UI. This tool is free to use. (https://visualstudiogallery.msdn.microsoft.com/44a26c88-83a7-46f6-903c-5c59bcd3d35b/)
There are also a variety of open source tools - Sitecore Courier is one example: (https://github.com/adoprog/Sitecore-Courier) This is designed to help automate deployment between Sitecore instances.
Both TDS and Courier are most suited to regular deployments, such as those during ongoing development cycles, since they both include automation to help decide what gets deployed. The standard Sitecore UI and the Sitecore Rocks extensions for package creation are better suited to ad-hoc deployments, since you generally pick the things to deploy manually.
A common best practice is to deploy your items along with your code using Team Development for Sitecore. This eliminates the need to create Sitecore packages every time you want to move items between environments, which in turn reduces issues caused by human error. As an added bonus, the items that you own as a developer (such as Templates and SubLayouts) can be checked into source control.
Full disclosure: I work for Hedgehog Development :)
I am planning an enterprise deployment of SiteCore...
Users can edit the content only on the backend servers.... and I was planning to DEPLOY in production only the required files & configuration required to run my site properly... (the Vanilla SiteCore site stripped out of the SiteCore folders...)
so I guess that I need 100% SiteCoreAssemblies and Config... more specifically I was wondering how to remove from the config all the unused stuffs required for the web edit and content approval roles....
let me know if there is any guidance / best practice... or any advise to improve the security and deploy the minimum configuration to run, would be appreciated...
Thanks Stelio
The only reason I'm digging this up is because I'm doing this in the near future:
Take a look that the "Configuring Production Environments" document that #Christian Hagelid pointed out.
More specifically: 1.2.2 Step 2. Clean the solution (optional)
Remove unnecessary files Delete the following files:
/Indexes folder - If you are not using indexes in your implementation.
Everything from the /sitecore folder except: -/service -shell/sitecore.version.xml -/login/default.css -/images
/App_Config/Commands.config
/App_Config/ConnectionStringsSQLite.config
/App_Config/Prefetch/Core.config
/App_Config/Prefetch/Master.config
/App_Config/Icons.config
/App_Config/LanguageDefinitions.config
/App_Config/Portraits.config
/WebSite/web.config.sqlite *
/WebSite/webedit.css
Remove or comment the following sections from the web.config file:
events
workflowHistoryStores
processors
dataviews
pageextenders
controlSources
replacers
fastCache for "shell" site.
watcher
commands
languageDefinitions
icons
portraits
publishing
watchers-media and watchers-config
ConfigWatcher from httpModules and system.webServer/modules
Filesystem database definition from databases
Remove or comment the following scheduled agents in the Web.config:
CleanupPublishQueue
CleanupAgent’s timing intervals should be adjusted if necessary
HtmlCacheClearAgent if not used
I challenge you to be brave and experiment with settings. Go through the web.config file line by line and make sure you understand them. I do this periodically to remind myself of features Sitecore has that I'm not taking advantage of. Try to remove some settings that you don't think you need and when they work and you're happy with them, share your findings.
Take FULL advantage of caching - Sitecore has wonderful options for caching and if properly configured your site will be fast, on the other hand if you don't properly configure caching your site could be really slow and or have weird issues with dynamic content being cached incorrectly.
Good luck!
There's a document called "Configuring Production Environments" which covers this. It's a little old but could be a good starting point at least.
Other documentation that might help:
Chapter 4.6 (How to: remove References to the Master Database) of the Scaling Guide
Chapter 7 (Content Delivery Server Optimizations) of the CMS Performance Tuning Guide
You should probably take a look at the Sitecore Security Hardening Guide to start with. It should provide you with a great start on best practices for setting up a secure production content delivery system.
As I recall, the easiest way to do this is actually through the license file. Sitecore should be able to provide a "webfarm" license that disables all editing functionality. There's no guide I know of as to folders you can delete, or sections from the web.config, and doing so will likely have undesirable side-effects.
I've read a lot of examples and tutorials about it. But none of the so called solutions helped me in my case.
Problem:
I have multiple web parts using the same resource files, so there is a solution for resource files that has a mapped folder to Resources with resx files in it.
When I deploy with resx file's "build action" property set to embedded or none, resources are not deployed to Hive/Resources.
When I deploy with "build action" set to "content", resources are deployed but the webparts that use resources get the error below:
Could not find any resources
appropriate for the specified culture
or the neutral culture. Make sure
"ResourceWp.Resources.ListNames.resources"
was correctly embedded or linked into
assembly "ResourceWp" at compile time,
or that all the satellite assemblies
required are loadable and fully
signed.
This is the place where my last healthy nerves couldn't resist the pain. I want to use the resx file neutral in culture like any simple asp.net webApp. I think something really simple is here that I'm missing because of my lack of knowledge about the assembly usage.
Through all the reading, I just couldn't understand one point that if I am able to use resource files like super.resx without writing super.en-US.resx (neutral I mean).
Because only difference that I have is this point, I don't use any tr-TR or likewise culture identifier and I use this project in a Turkish language-pack installed and in a site created by selecting "Turkish" as language.
But in my opinion, that shouldn't be the point, right?
Summary:
I want to deploy my resource in Hive/Resources and them to be available to my webparts
I have tried:
http://johanleino.wordpress.com/2010/11/08/working-with-resource-files-in-sharepoint-2010/
http://weblogs.asp.net/jevgeni/archive/2010/02/02/using-resource-files-in-sharepoint-2010-and-visual-studio-2010.aspx
kind of approaches. But didn't accomplish any success with them.
I hope, someone can help me, thanks in advance.
It seems as it is necessary to place the resource files in App_GlobalResources folder. This approach worked well in my (similar) case: https://sharepoint.stackexchange.com/questions/20851/localizing-asp-markup-in-webpart-issue
Given a project I'm about to start there will be documentation produced.
What is the best practice for this?
Should the documents live with the code and assets or should there be a separate documentation store?
Edit
I'd like a wiki but I will need to print the documents etc... It's a university project.
It really depends on your team. Where I work, we keep documentation in a wiki which is linked in with our team website. For the purposes of shipping documentation, the wiki can be exported and we run it through a parser that "fancifies" the look and feel of the documentation for customer purposes.
Storing the documentation with the code (typically in your source repository) is not a bad idea. Just make sure to keep them separated. For example, keep a docs folder which is on the same level with your src folder in your repository. This way, you can quickly ship the current documentation, you can easily track revisions, and anybody new to the project can immediately jump in without having to go to multiple locations for information.
Storing it in source control is fine.
This is an interesting question -- basically, what others are saying is right about generated documentation, source files and templates/etc. should be stored in source control and generated during your build process.
As far as requirements/specs/etc. documentation, I have worked both ways, and I very much prefer using SharePoint or a Wiki/document portal that is designed for document sharing/versioning. The reason is, most non-developer folks aren't comfortable working with source control systems, and you don't gain any of the advantages of intelligent merging if you are using a binary format like Word. Plus it's nice to have internet-based access so you can reference and work on the docs in a distributed team without people having to install extra software.
Here's a 2017 summary of the options and my experience:
(extreme 1) Completely external (e.g. a wiki, Google Docs, LaTeX, MS Word, MS Onedrive)
People aren't bothered about keeping it up to date (half of them don't even know where to find the page that needs updating since it's so out of the trenches).
wiki platforms are “captive user interfaces” - your data gets stored in their proprietary schemas and is not easy to examine with a simple text editor (Confluence is even worse in that you have no access to the plaintext content at all anymore)
(extreme 2) Completely internal (e.g. javadoc)
pollutes the source code, and is usually too low level to be of any use. Well-written source code is still the best form of low level documentation.
However, I feel package-info.java files are underutilized.
(balance) Colocated documentation (e.g. README.md)
A good half way solution, with the benefits of version control. If a single README.md file is not enough, consider a doc/ folder. The only drawback of this I've seen is whether to source control helpful graphics (e.g. png files) and risk bloating the repo.
One interesting way to avoid this problem is to use plaintext diagram tools (I find Grapheasy and Text Diagram to be a breath of fresh air).
plaintext can be easily read even if your rendering engine changes as the years go by.
Github's success is in no small part thanks to its README.md located in the root of the project.
One tiny disadvantage of this approach though is that your continuous integration system will trigger a new build each time you make edits to the README.md file.
If you are writing versioned user documentation associated with each release of the product, then it makes sense to put the documentation in source control along with its associated product release.
If you are writing internal developer documentation, use automated internal source code documentation (javadoc, doxygen, .net annotations, etc) for source level documentation and a project wiki for design level documentation.
I think most of us in the industry are not really following best-practices and it of course also depends a lot on your situation.
In an agile environment where you would have a very iterative process of release, you will want to "travel light". In this particular case, Jason's suggestion of a separate Wiki really works great.
In a water-fall/big bang model, you will have a better opportunity to have a decent documentation update with each new release. Also you will need to clearly document what version of the requirements was agreed on and have loads of documentation for every tiny change you do to requirements (due to the effects it has on subsequent stages). Often if the documentation can live together with the version controlled source code it is the best.
Are you using any sort of auto-documentation or is it completely manual? Assuming that you are using an auto-documentation system, the documentation is more or less generated on the fly, and would be part of the code itself.
To me, (assuming that it's possible with whatever code you are using), this would be the preferred method of handling it, as you wouldn't need to maintain the documentation source at all.