We have a WCF service that needs to be deployed to 200 plus customers' servers. We would like to be able to make a portion of the web.config available for customization by using the configSource attribute like so:
<bindings configSource="bindings.config" />
This allows us to overwrite the main web.config file with future upgrades while not overwriting customers' own modifications to the sections that we decide to externalize this way. Unfortunately, there's a problem with this - according to this article, "When you use the configSource attribute, you must move the entire section to a separate file because there is no merging of element settings." This means that any section we put in an external file is now outside of our reach for upgrades and changes without having to mess with the external files that the customer may have made modifications to.
Is there any way around this? Can we have our cake and eat it too, or do we have to decide between having control ourselves and giving our customers flexibility?
Well it appears there's no way around this, you can only do it one way or the other. In the end the decision we made was to use configSource and externalize certain portions of the web.config, knowing that those would be outside of our control but that the vast majority of our web.config would still be available for future modifications.
Related
I built a virtual filesystem (not a namespace extension) for Windows which acts as a frontend of our document management server consisting of files and folders. In order to be able to display some metadata of the DMS objects in Windows Explorer as additional selectable columns, I successfully provided properties to the Windows Property System by implementing a COM Property Handler. Wheras normal property handlers focus on specific file types for which they feel responsible, my Property Handler adds properties to all files regardless of their type. Because Property Handlers can only be registered on the file type level, I registered my handler for about 30 types under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\<.Extension>
However, I did not manage to register the Property Handler for folder objects. Since all objects in our file system are virtual I build the property store (IPropertyStore) by implementing IInitializeWithFile instead of IInitializeWithStream. The properties are requested from our DMS with the path of IInitializeWithFile acting as key and were not read from an objects content. This concept would work for folders as well.
For getting called on folders I tried to associate the handler by registering under different well known identifiers like Folder, Directory, AllFileSystemObjects and * instead of the file extension without success.
I also didn’t find anything in the MSDN documentation regarding this aspect.
Is there a way to register a Windows Property Handler on folders? Or is there some other way to add custom columns to folders in Windows Explorer?
I'm not sure if it is possible to do this.
Property handlers are clearly not the right approach, they are system wide and there can only be one per file extension. They should only be implemented by the software that "owns" the file extension and can parse the file to extract properties.
The old column handlers would have been your best bet (IMHO) but they are officially dead and you already said you can't use them.
Have you considered creating a namespace extension? Either as a root item somewhere (Desktop or My Computer) the way My Documents used to work in 2000/XP or maybe something more along the lines of how OneDrive works?
I'm not sure if desktop.ini files work in the root of a drive but it might be worth looking into. You would then find yourself in the poorly documented land of [.ShellClassInfo] and its CLSID, CLSID2 and UICLSID members. The general idea would be to act as a IShellFolder proxy on top of the "real" IShellFolder so you could create a multiplex property store. I think there are some (undocumented?) property keys you can override to change the folders default columns and tooltips as well.
There is also something called a delegated folder that allows you to play with nested PIDLs but the documentation is once again pretty useless so I'm not sure if this is something worth looking into.
A 3rd option is to pretend to be a cloud storage provider. I don't know if this gets you any closer to your goal and you would still have to implement some NSE bits to get to the point where you can layer yourself on top of the underlying IShellFolder. This feature is rather new and only documented to work on Windows 10.
The inner workings of how Explorer/IShellBrowser is connected to the IShellFolder/IShellView is one of the least documented parts of Windows. There are hundreds of undocumented interfaces. Explorer gives DefView special treatment leaving other 3rd-party implementations out in the cold.
My feeling is that there is no clean solution to implement this on top of a drive letter but you might get lucky, if Raymond Chen drops by he might have some tips for you...
I just can't get a handle on how to correct this one. It cropped up about a week ago, and I don't know what change I made could have caused this. We use SVN and I rolled back changes I made of possible culprits of these errors but I am still getting the following errors when I build my asp.net webforms project:
The namespace <global namespace> already contains a definition for 'TrxStatus'
The namespace <global namespace> already contains a definition for 'MessageStatusType'
These two errors are repeated 5 times (10 errors total) and the source files are code generated for the loads of webservices we have in the project.
The file names are App_Code.34kjg234jh1.cs (made up, but you get the idea) and at the top of each one it tells me where it is being generated from:
App_Code\App_WebReferences\SomeService\SomeWebService.wsdl
If I go into the .wsdl definition I believe they do all live in the same namespace based off of this line: (Note, I am not a .wsdl wiz, so tell me if I am wrong)
<s:schema elementFormDefault="qualified" targetNamespace="http://www.thirdpartysite.com/Soa/Foundation/">
<s:import namespace="http://www.thirdpartysite.com/Soa/Foundation/MessageDefinition.xsd" />
This is an application inherited from our prior developer (its a one developer shop here, so I usually get to poke around in the dark) so I don't know why we have about 7 different web services in the application, all with that namespace definition and ALL with the offending 'TrxStatus' and 'MessageStatusType'.
I don't want to change the namespaces, because it is the right namespace (I believe), but I also need this conflict to go away. I am not sure which direction to go.
I attempted to go into one of the .wsdl files and change TrxStatus to TrxStatus_Whatever but that gave me this error:
Unable to import binding 'MyWebServiceName' from namespace http://www.thirdpartysite.com/SOA/Foundation
Another possible clue is I am getting a ton warnings from the various web services that say something like this:
The 'http://www.thirdpartysite.com/Soa/Foundation/MessageDefinition.xsd:SomeElementName' element is not declared.
Any suggestions on possible solutions to this? What is the root cause? Please don't tell me I need to re-write all these services....
I'm by no measure an expert, in fact I do very little ASP.NET & Services.
BUT. It sounds as if there are conflicting imports (i.e usings) that are pulling in types with the same names.
proj1: A.SomeType
proj2: A.SomeType
You can add references to both projects and it play just fine (I believe). But the difficulty comes when you import both namespaces because the type names clash.
You can access the correct type by using the global:: accessor.
You can even use global:: in a using statement.
using A = global::[path to correct project and type here]
Not sure if it'll be much use to you, but there's more info on global:: here:
http://msdn.microsoft.com/en-us/library/c3ay4x3d.aspx
My application needs to be able to serve up static content which can be contained in a number of different places (directories and/or via the class loader). So, for example, a resource /static/file.html might be found in /dir1/file.html or /dir2/file.html; I would want it to try /dir1, and if not found there, then /dir2, and so on.
With servlets in Jetty, I can use either a HandlerList of DefaultServlet, to sequentially try to handle the request from each directory until satisfied, or even easier a single DefaultServlet with a ResourceCollection.
I can't see a way to do something similar in restlet, without writing a class to specifically do this. I could modify Directory to handle multiple sources (in a similar way to DefaultServlet with ResourceCollection), or write a new Restlet which tries each contained Restlet sequentially, until successfully handled (like HandlerList). But before I do that, am I missing another way that already exists to achieve this?
thanks,
Stuart
I confirm that Directory doesn't know how to handle multiple source directories. It would be a nice to add support for this and contribute it back.
I have a multiple-site Sitecore project. I know how to deal with error pages via the webconfig's ErrorPage, ItemNotFoundUrl, LayoutNotFoundUrl, LinkItemNotFoundUrl for one site.
However, I'm wanting to display a different error pages for each site. How can I accomplish this?
In any case, you can probably store the URLs of the error pages for each site as attributes of the /configuration/sitecore/sites/site elements in web.config by extending the Sitecore.Sites.SiteContext class (see for information about extending existing classes).
The SDN forum post provides more information specifically about the 404 /ItemNotFound condition, including an example of an extension of Sitecore.SItes.SiteContext.
For ItemNotFoundUrl, I think it depends on whether you use an item or a file as the 404 page. If you handle 404 with items, then after the item resolver, add a processor to the httpRequestBegin pipeline to set the context item to the 404 item for that site if the context item is null. If you use files, then I think override Sitecore.Pipelines.HttpRequest.ExecuteRequest.HandleItemNotFound() and Sitecore.Resources.Media.MediaRequestHandler.DoProcessRequest() and update the corresponding references in the web.config file.
For ErrorPage, I think you would have to override Sitecore.Pipelines.RenderLayout.SecurityCheck.Process and update the corresponding reference in web.config.
For LayoutNotFoundUrl, I think you would have to override Sitecore.Pipelines.HttpRequest.ExecuteRequest.HandleLayoutNotFound, and update the corresponding reference in web.config.
For LinkItemNotFoundUrl, I would probably add a processor to the renderField pipeline to perform replacement of the default value of the setting with the value that applies for the context site.
If this is a common requirement, we should turn it into a Sitecore Shared Source project, or add it to an existing project.
There's an entry in the SDN scrapbook about how to do this for a multi-site install.
There is a Shared Source project which should fit the requirements is most parts. It's called Sitecore Error Manager.
Hope that helps.
I am looking for a method of storing Application Messages, such as
"You have logged in successfully"
"An error has occurred, please call the helpdesk on x100"
"You do not have the authority to reset all system passwords" etc
So that "when" the users decide they don't like the wording of messages I don't have to change the source code, recompile then redeploy - instead I just change the message store.
I really like the way that I can easily access strings in the web.config using keys and values.
ConfigurationManager.AppSettings("LOGINSUCCESS");
However as I could have a large number of application messages I didn't want to use the web.config directly. I was going to add a 2nd web config file and use that but of course you can only have one per virtual directory.
Does anyone have any suggestions on how to do this without writing much custom code?
In your Web.config, under appSettings, change it to:
<appSettings file="StringKeys.config">
Then, create your StringKeys.config file and have all your keys in it.
You can still use the AppSettings area in the main web.config for any real application related keys.
Put the strings in an xml file and use a filewatcher to check for updates to the file
Put the strings in a database, cache them and set a reasonable expiration policy
You can use ResourceManager class. See "ResourceManager and ASP.NET" article at http://msdn.microsoft.com/en-us/library/aa309419(VS.71).aspx