I have a WPF application that accesses a number of WCF services. The WCF service addresses used in dev are different than those used in production (though their WSDL signatures are identical). What is the best way to setup the config files so that the proper service url is used for each type of build?
You can consider using a NANT process after build that change the config in a different way, here a discussion about that. An alternative is to create a MSbuild custom task, as discussed here.
Related
What is the best way to dynamically provide configuration to a vespa application?
It seems that the only method that is talked about is baking configuration values into the application package but is there any way to provide configuration values outside of that? ie are there cli tools to update individual configuration values at runtime?
Are there any recommendations or best practices for managing configuration across different environments (ie production vs development) ? At Oath/VMG is configuration checked into source control or managed outside of that?
Typically all configuration changes are made by deploying an updated application package. As you suggest, this is usually done by a CI/CD setup which builds and deploys the application package from a git repository whenever that changes.
This way it is easy to ensure changes have been reviewed (before merge), track all changes that have been made and roll them back if necessary. It is also easy to verify that the same changes which have been deployed and tested (preferably by automated tests) in a development / test environment are the ones that are deployed to production - because the same application package is deployed through each of those environments in order.
It is however also possible to update files in a deployed application package and create a new session from this, which may be useful if your application package has some huge resources. See https://docs.vespa.ai/documentation/cloudconfig/deploy-rest-api-v2.html#use-case-modify
I have a multi-module maven based project which has a number of Spring Boot applications, a couple of which (lets call them A and B) connect to a database (I have a separate module with the database related code on which both applications depend.) I am also using Flyway to maintain the database versioning and maintain the database structure.
What is the best approach to maintain the database properties? At the moment I have 3 places where I am repeating the same thing. I have the application.yml of module A and application.yml of module B, since both are separate Spring Boot applications. Then I have the Flyway plugin configuration again which needs the properties in the pom.xml to be able to perform its tasks, like clean, repair and migrate.
What is the proper approach to centralise and externalise this information, like the database URL, username and password? I am also facing the issue that each time I pull the new code onto the test system I have to update the same data again because it gets overwritten, and the database configuration on the test system is different from my local development environment.
What is the best strategy to manage this?
Externalize your configuration into a configuration module. This, of course, depends on how flexible Flyway / Spring Boot are from using classpath based properties.
Look at something like archaius and make your configuration truly externalized, centralized and dynamic by having it backed by, say, an external datastore. More work involved here but gives you additional benefits, like being able to change config in one place and have them dynamically picked up in running applications everywhere.
It's not an easy problem to solve and definitely involves some work to make your tools cooperate by hooking into their lifecycle.
For your flyway you could use the maven-properties-plugin. In that way you can externalize the credential to a properties file. An example is described here.
For the spring-boot application I will recommend the spring cloud config . With the spring cloud config you can externalize your config to a git repository which can be discovered over an Eureka Service, e.g. like here. I will consider to restructure the modules to independent microservices. A good infrastructure for a microservice based architecture provides the JHipster project.
I am working on a project requiring communication between the Presentation layer (MVVM based client) and the Business layer. The application is to be installed on a single machine, and as such could have been executed using a .net remoting based approach. However, I have been suggested to use WCF since .net remoting is deprecated and WCF is the way to go.
So I implemented WCF Service as a WCF library project. I added a service reference (using visual studio tool by discovering services in the solution), which was successfully added on the client side. All works well, since during debug session visual studio launches the service library and the client can connect to it successfully.
Now Since the client and service host will be installed on same machine, I was thinking of using named pipes transport and self hosting for the WCF service. Here is where this gets very confusing to me:-
Since the MVVM client is the "main" app (since it is the application frontend), the client will be launched first. I am unable to come up with a solution to launch the service host "on-demand" when the client needs the same.
What are the solution I can use to do what I require for 1? I am not sure of using a continuous service through windows service for something that will be required "on-demand".
Please suggest clean approach to implement a way to launch "on-demand" service.
Thanks in advance.
I'm not quite following you here. MVVM is cake and really doesn't have anything to do with your problem. Using a servicebased architecture is a must today, I just want to smack every old guy/gal sticking to direct SQL on the client side, and don't see the dangers with that.
Well anyhow, you may solve this different ways. WCF is BIG, to big in my opinion. One way to use it, common on small applications like apps(WP8.1, 8.1 apps++), is just to connect, call the method you need and the close the connection. Case solved, given that I understand your needs. The otherway is to keep the session alive for each service... (ugh, loadbalancing etc).
I've been working on large LOB applications the last 4 years my self, what I can tell, is that if I were in charge, I would have done it very differently. For once I would used JSON endpoints with SSL over HTTP, and the json.net serializer. The datacontract serializer which is the default in WCF, is not good news at all. JSON allows easy communication with JavaScript based applications, and the serializer doesn't break like porcelain as the datacontract serializer does. Address/baseaddress may be stored in your config file, so it may be changed upon deployment(you probably have many servers, for different environments).
This is a really old post covering the subject(supporting SOAP aside JSON); REST / SOAP endpoints for a WCF service
Don't be stupid and just call your services directly now! Use the interface(Wrap if necessary) and feed it to your viewmodels for proper TDD! It will also allow you to completely replace WCF with another form of communication.
There also are alternatives to WCF.
IIS? Hosting WCF in IIS rather than a proper service? No way, flush that idea down the waterloo ;) (internal joke)
EDIT:
BTW: Your service must ofc already be running for your client to connect to it! Or nothing will be listening to your configured port. If you are selfhosting, you can use parameters to start in debug mode, that is start your service like a regular application you may debug. In Program.cs;
if (args.Length > 0 && String.Equals(args[0],"debugmode", StringComparison.OrdinalIgnoreCase)
{
Service1.Create(); // Debugging!
}
else
{
// Hosting
service = new Service1{ServiceName="YourService"};
ServiceBase.Run(new ServiceBase[] {service};);
}
Hope it helps,
Cheers,
Stian
So, i'm building my first SL application.
I tried to use the MVVM approach, and I think that's the way for me.
Basically, it's a simple application which shows data to the user, the data source is local (maybe in the future will be centric, but right now this is not the case), and the data should be retrieved by:
A. Calling file system's reading
and
B. Method calls from External DLLs
So, as I said, I started to work with MVVM (used this tutorial). I have 3 components: the service, the SL application and the project that host the SL app (excuse me if i'm not using the exact proffecional terms...).
My question is: Do you think that I've chose the right design? if so, is there any way not using IIS to host the service or is it a must? (I don't want to spend time on adminastrative tasks on clients' computers), because as I said, the data is local at the moment and IIS feels unnecessary.
I'll appriciate every comment on this. Thanks!
EDIT:
I'll try to simplify my question: I need my SL app to communicate with some kind of service - that will be able to take requests and reply back to the app.
This service suppose to be able to use .net dlls, and this service should be locally on each client run the app.
EDIT:
I noticed the Self host option.
Does anyone has any experience with it?
If your question is about: You having access to a database server somewhere, you should try WCF RIA Services. This will allow you to create service for each entity and the service will get included into your host project or you can even create a WCF RIA library.
As suppose to your MVVM pattern. I prefer splitting my Views from my ViewModels In different projects. I like to see them as a seperate layer.
Actually using ria services may mean that you have a number of services which apply to one user, but yes they are specific to the user. Which file system would you be attempting to access? The client or the server?
I finally decided to go with XBAP(WPF XAML Browser Application).
It suited perfectly to my requirements:
1. no deployment issues - just press a link, and .net enviroment will do the rest (downloading the needed assemblies, install them and finally run the app)
2. it's hosted on a browser
3. no IIS is needed!! it's a client-only application
Currently I have a working Silverlight application that uses .Net RIA Services.
It's structure:
Client-side
Application.Client.UI.dll (Xamls and
basic UI stuff)
Application.Client.BL.dll (Contains the Link to RIA and most of the business logic)
Server-side
Application.Server.Data.dll (Server-side dll that holds the Entity-model and it's generated domain service)
Application.Server.Web.dll (Only the ASP.net hosting container, which references the
Application.Server.Data.dll)
I placed most of the business logic on the client side (Application.Client.BL.dll) for better user-experience (fast reactions) and to free up server resources. My challenge is now to re-use this client-side dll including it's RIA data access capabilities, in a server-side windows service. I'm wondering, is that possible at all? Is the Application.Client.BL.dll still able to consume the existing RIA service, or does that dll require the Silverlight runtime to identify/locate it's service target, and therefore will not work anywhere else.
Curious for your answers
You really shouldn't put any business logic on the client, the guys in security and / or architecture will hate you for it ;-). Furthermore you can't use Silverlight assemblies in ASP.Net or Desktop projects and vice versa. If memory serves correctly, Silverlight uses an entirely different CLR altogether.
I encountered similar needs when working with compact framework assemblies I also wanted to compile for the full framework. I'll describe how I would work around this scenario.
If there exist any issues referencing the Silverlight assembly, consider building two projects as follows:
Project #1 would be your Silverlight library, and should contain all the source files you want to use on the client.
Project #2 would be your Windows Service. Instead of including source files directly, use the "Add Existing Item", find the original source file in project #1, then (and this is the magic), drop down the Add button to choose, instead, choose "Add as Link".
By including the source file as a link, you retain the ability to maintain your source code in one location, but add the ability to compile your code for multiple frameworks. As long as the code relies on assemblies available in both the Silverlight framework and the full .NET framework, then you're money.
Now, regardless of whether you choose a multi-project approach, know that domain context classes have additional constructors that allow you to specify contextual information, such as the URL, for the corresponding domain service. I use the following code in one application to construct a domain context for a domain service that provides personnel data:
var context = new PersonnelDomainContext(
new Uri(ConfigurationManager.AppSettings["PersonnelServiceUrl"]))
In this case, the URL looks something like:
http://website-url/Services/Hyphenated-Namespace-PersonnelDomainService.svc
Of course, when writing a Windows Service, nothing is stopping you from referencing the server-side domain service (not context) assembly directly. With the domain service in hand, you can instantiate a service instance without all the additional configuration and without the additional network XML payload. There are trade-offs to this approach, such as forfeiting centralized configuration management (such as connection strings), but depending on your circumstances, you may find the trade-offs to be worth it.
Happy coding!
Have you considered using fork-reuse? Take a look at:
http://sharednow.blogspot.com/2011/05/its-not-just-reuse.html