I have a class that inherits from SPItemEventReceiver and implements ItemAdded, ItemUpdated, and ItemDeleted. These all work just fine and I'm getting the data I need.
However, I want to push some of the data to a 3rd party server via a web service. What is the best way to configure the external dependency of the web service for various environments (dev/test/production) without hard-coding the end point for each environment?
I'd prefer to avoid any static *.ini type files if possible. Can I add a configuration section to SharePoint's web.config and read it from the event handler?
Yes, best place to store that settings is web.config file. Below, some related articles:
Event handlers configuration settings best practices
Reading Settings from the Web.Config file from an Event Handler
Think of it like that - what would happen if you created yet another site of the same type and having the same event receiver and everything. Would you still use the same configuration? Is it a setting per each list? Per website? Per server farm? If you decide it's a server farm setting, then web.config is good for you. If you think that each web needs different config, then you have to persist the configuration somewhere else. For instance, if it's at web level, you can write your config string to SPWeb.Properties. This setting can later be read easily from that object, for instance SPContext.Current.Web.Properties["RemoteWebServiceURL"]. You can also set the value form a tiny PowerShell script. A SPList object has a similar property bag.
Related
I have a different developer, besides me, working on a Asp.net project (.net 4.5) on Visual Studio. The problem is that I use http://localhost/MyProject as my local server url, while he uses http://localhost:51123, probably because default port is already taken by another server.
The problem is when he commits a change to .csproj file, it change this configuration for me , and i have to change it back. And he's probably having the same problem when I change.
Is there a way for us to use different webserver, while allowing us to commit changes do .csproj file? (For when we add a new class or page, for instance).
How do you deal with that in your projects?
You can have 2 entries in appsettings configuration like
"AWebserver" : "AProject",
"BWebserver" : "BProject"
where the url is passed use the Configuration object to read from the appsettings with your particular server key. It will make it a bit easy to
as you only have to change the key that is being passed in the configuration object.
I have a solution that contains two projects. One project is a Windows Service that contains a few classes for performing various functions. The other project is a Windows Form Application that is meant for doing various testing and performing task that the service accomplishes on demand. For instance, the service will do a few various task at a certain time interval, but if you wanted to perform one of those task before the time interval has elapsed, you could load the Windows Forms Application and execute one of the task immediately. The Windows Form Application (from here referred to as the tester) references the Windows Service (from here referred to as Service) project. When the Tester loads, it creates an instance of one of the classes from the Service. Whenever buttons are pressed to perform the task, it references that instance that was created and calls the various methods of the class. The Service has uses application settings for the configuration, and thus has an app.config. The configuration settings are accessed using [ProjectName].Properties.Settings.Default.[SettingName]. When the configuration settings for the tester are changed on its own app.config (or exe.config after release), the settings are refreshed without a problem. If the tester is closed, configuration is modified, and then reopened, the new settings will be populated. If the Reload method is called on the Settings, the configuration is refreshed without a problem. The Service performs in the same way. The configuration settings are can be updated without a problem.
The problem is that if configuration changes need to be made on the service, when the service methods are called from the tester, the configuration does not take the new settings. Whatever settings the project was built with will be used. I cannot get the tester to recognize that the app.config/exe.config for the service has changed, and the new configuration should be reloaded and used instead of whatever configuration was used when the project was built in visual studio. Perhaps it I am not educated enough about this topic, but it seems to me that the app.config is rolled up into the .exe file created by the Service whenever it is built.
I have tried encapsulating the Reload method for the Service and calling it, and it doesn't seem to make a difference.
I have an example project that performs as is described above on a very basic level. The ideal goal is to be able to modify the exe.config file or files on the fly and have both the Service and the Tester pick them up without any problems. If you would like to see exactly what I mean from a coding perspective, an example project can be found here: example solution
Any help would be greatly appreciated. Thanks you for your time.
Update
I have managed to find A solution to this, but I am still curious if there is a better way. By using an app.config that is shared between both projects and using the Configuration Manager instead of App Settings, everything works as it is expected to. I prefer to use App Settings if at all possible; however it will work to use a shared app.config and the Configuration Manager pointed at that app.config.
One option is having both programs load from the same configuration file:
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.openexeconfiguration.aspx
Found the solution. An app.config must be added to the solution as is described above in my update. Once linked like that, you can add a settings file to the project and add settings/configuration to the project and they will be added to the solutions settings file. This will move with the build and fix the problem I was having.
This is a common problem for me. I have a solution that contains a Form App or two, a couple of websites(Intranet, External site kinda thing) and a class library where I want to store my data objects to be shared among the other project mentioned.
Normally, I'd have my connection strings stored in web.config and app.config files. However, with the class library, this isn't really possible. Not without passing in configuration information each time I want to access data. I'd prefer not to do that.
What's the best way to solve this problem?
If you put your connection strings in the web.config and the app.config of the referencing applications the Dll's will read them fine. If you want them shared you can put them in a machine config. You could also put them in a separate file and reference them from each web and app config.
I've currently written code to use the ServiceContractGenerator to generate web service client code based on a wsdl, and then compile it into an assembly in memory using the code dom. I'm then using reflection to set up the binding, endpoint, service values/types, and then ultimately invoke the web service method based on xml configuration that can be altered at run time.
This all currently works fine. However, the problem I'm currently running into, is that I'm hitting several exotic web services that require lots of custom binding/security settings. This is forcing me to add more and more configuration into my custom xml configurations, as well as the corresponding updates to my code to interpret and set those binding/security settings in code.
Ultimately, this makes adding these 'exotic' services slower, and I can see myself eventually reimplementing the 'system.serviceModel' section of the web or app.config file, which is never a good thing.
My question is, and this is where my lack of experience .net and C# shows, is there a way to define the configuration normally found in the web.config or app.config 'system.serviceModel' section somewhere else, and at run time supply this to configuration to the web service client?
Is there a way to attach an app.config directly to an assembly as a resource or any other way to supply this configuration to the client?
Basically, I'd like attach an app.config only containing a 'system.serviceModel' to the assembly containing a web service client so that it can use its configuration. This way I wouldn't need to handle every configuration under the sun, I could let .net do it for me.
Fyi, it's not an option for me to put the configuration for every service in the app.config for the running application.
Any help would be greatly appreciated.
Thanks in advance!
Bryan
Create a custom class deriving from
ChannelFactory.
Override the protected
CreateDescription method. In the
override, you need to...
Call base.CreateDescription().
Read in your custom configuration.
Create a custom ServiceEndpoint based
on your configuration. Don't forget
the bindings, behaviors, etc.
Return that custom ServiceEndpoint.
More details HERE
The following couple links talk about loading WCF Configuration settings from config files other than the app.config. May be what you are looking for but not certain.
http://blogs.msdn.com/dotnetinterop/archive/2008/09/22/custom-service-config-file-for-a-wcf-service-hosted-in-iis.aspx
http://weblogs.asp.net/cibrax/archive/2007/10/19/loading-the-wcf-configuration-from-different-files-on-the-client-side.aspx
Are your proxy classes deriving from ClientBase<T>? If so, then there is a constructor that accepts a Binding and an EndpointAddress. You should be able to use those instead of the corresponding configuration data.
I have an self hosted WCF server with hard coded configurations. the server worked fine until I tried to implement some new configurations functionality (changed ports, added ssl) the new config setting did not work (urrr.... ) and I find it hard to locate where are the problems in my code.
instead of digging inside the code that declares the WCF object, I thought about different approach:
Is there any way to dump-to-file those hard coded WCF configuration (the entire ) into app.config like text file after all configurations are loaded? this will enable me to have a easy global view of the entire settings ..
mmm .. .by the way, does anyone know a way that will do the translation to the opposite direction? config to code.
Any advice will be welcomed!
ofer
I don't think you will find an automatic way to dump your c#/vb code somewhere and have your configuration converted to the config file xml schema (and vice-versa), however if you ask my personal opinion, if you don't have a strong reason to hard-code your configuration in your code (even if you do so, I would rethink that), you should move the wcf configuration out from your code. Configuration is not responsibility of the code. It is configuration, meaning that if you need to change the "configuration", you don't need a new build.
In your code, you should just concentrate in the service consumption logic, leaving the configuration to the back-end engine take care of it. Remember that sometimes you may need adjust some settings, like service throttling, max/min buffer size, MaxItemsInObjectGraph quota, etc. If hard-coded, means a new deployment. If in a config file or other repository, means a simple configuration change.
If you have all your configuration in a config file, when you move your code from environment to environment (Dev, DIT, QA, UAT, Pre-Prod, Production), you can have different settings between environments, if required (because the port number you used is already in use or is blocked in the firewall). The release management team will just configure it properly in the config file.
If you want more control over your service configuration, you could consider creating a factory service for your services, where will get all your configuration from a centralized place (database, xml file, etc), and you will configure your code on-the-fly.
I hope it helps...