I've a .Net based thick client winforms application deployed to the clients.
I need to use TransactionScope class [System.Transactions] in the code for handling transactions on the oracle database.
Looks like this class requires oramts.dll on the client machine.
See here:
Using transaction scope and querying
Given this, is it a good idea to use this class in a thick client application?
Because, then all the client machines would need to have this dll and other dependancies present on their machine.
Plus, if these dlls are COM based, then they would need to be registered in the registry too.
Is oramts.dll a COM dll?And can anyone please let me know what are its dependancies?
Please advise.
Thanks.
TransactionScope is a very elegant and errorsafe way to handle transactions in the code. It's definitely worth having to add another dll.
By the way - are you sure that the dll wouldn't be needed if you created the transactions by hand?
Related
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
We are developing a WCF REST service which will be consumed by a desktop WPF application and will also be a source of data for the ASP MVC4 website.
So far I've run into countless technical issues and most importantly I am worried about the future of the Microsoft.OData.EntityFrameworkProvider. (Please check blog comments here).
The issues include:
There is no easy way (without using DTO) to add properties on the service entities which will be passed through OData but won't be stored in the database Actually there is an easy way:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.ComplexType<CustomType>();
}
There is no easy way (without parsing XML or using DTO) to store properties on client entities without them being sent to the service (v5.6.0). The "hard" way is to hook into RequestPipeline and ResponsePipeline:
Configurations.ResponsePipeline.OnEntryEnded(OnReadingEntry);
Configurations.RequestPipeline.OnEntryEnding(OnWritingEntry);
using DTO is cumbersome to say at least, automapper helps with retrieving of IQueryable results but updating entities requires full implementation of IUpdateable, which actually works on DTO but is required to update entities so implementation of it is very tricky if even possible (I searched for existing solutions and these mostly cover in memory data source so I implemented a working solution but without links, I can dig it from source control if anybody is interested). Tested on v5.6.0.
Client entity containing dynamic field will crash when retrieved from a service (checked on 5.6.1)
accessing DbContext from EntityFrameworkDataServiceProvider requires a hack
This package has not been updated for almost half a year and this fact itself is very worrying.
My question is what Microsoft or open source alternatives to Microsoft.OData.EntityFrameworkProvider link between EF context and a client are suitable to replace this supposedly dead library? The critical requirement for such a link would be to have a tracking client-side context and entity framework 5 or 6 compatible service.
Is Microsoft.AspNet.WebApi.OData a good solution also for desktop applications?
Are there any other Microsoft or open source projects have similar capabilities?
For WCFDS update, you can refer to Future Direction of WCF DS service.
In the issues you listed, I am sure that issue 1 can be easily resolved in web api by tag [IgnoreDataMember], here.
For Issue 2 and 4, one suggestion is you can add a data layer in client, which can handle extra data model and dynamic field
Just a couple of thoughts...REST is not the same as OData...so your question is confusing. If you meant WCF Data Services, then definitely go with the new WebApi. As Maya's link shows, The WCF DS team announced they are basically done.
However, your client is usually agnostic of what technology you are using for odata and its data layer...its a disconnected architecture. So if you have a mapping impedence on the server side, that is one issue, but which client is consuming the odata ought to be irrelevant. But likely I did not understand your stated problem correctly...Do you mean that you own both the client and server and want to share the entity class definitions? If you are that tightly coupled, you can add service resources customized for the client, and others customized for your MVC app.
For some practical workaround, WCF DS offers query interceptors, that let you manipulate outgoing data. The new WebApi is basically works from controllers and gives you full control over intercepting the requests and manipulating what needs to be done with the data.
Finally, just a suggestion for your desktop client...Lightswitch works wonders with oData...point and click...it generates your proxy and client model on the fly and gives you huge control over the client and what it does with the responses from the server.
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
I am working on an in-house, iOS app that will need read-only access to a SQL Server with multiple databases. I know the stock answer here is "write some web services", but I'd like a solution that is self-contained. Is there any way to directly connect to a SQL Server database from an iOS application? I'm thinking something like a basic ODBC connection.
I've seen a lot of users asking this question, but very few answers other than "write a web service." Is that really the only way?
A web service is indeed the only way, but Red Gate's written one you can reuse:
http://www.mobilefoo.com/iSqlServerSDK.html
http://labs.red-gate.com/Tools/Details/iSqlSDK
It's not officially released yet, just in beta, so keep in mind that features & prices may change.
Actually the easiest way is to create a MVC 3 or 4 asp.net web application. call the web methods. You don't need any API to pay for.
I use SBJson to serialize domain object and then send the objects as serialized jSOn to MVC 3. It's super easy to do. I even send images with base64, so it's .net compatible.
See my blog post with sample code:
http://nickturner.wordpress.com/2012/10/09/107/
So, after much searching and trial and error, unfortunately the best (only?) way I've found is indeed using Web Services.
Fortunately, Linq to SQL makes the WCF-creation-side incredibly easy. Once I got someone at work to walk me through setting up a Windows web server and adding the web service (and buying access to an online web server), the Windows side was up and ready to go.
I'm still working through all of the syntax stuff on the SOAP interaction side, but keeping my different methods somewhat similar in structure allows me to tinker a little until it works. By this time, I think I've gotten it to work pretty well.
So, both answers I got back were (disappointingly) correct. The only way to interact is through a Web Service. Even the 3rd party solutions they mentioned were really just convenient wrappers around the same type of technology. As it turns out, I'd rather have finer control over the process.
One word of advice: Get a real, external web server. I tried doing this on a non-Server Windows VM on my iMac/MacBook Pro, and it was like pulling teeth! Once I actually got access to an external, full, stand-alone web server, the process was much more streamlined and easy. Do yourself a favor and take that headache out of the equation!
There was a SQL ISAPI extension as part of SQLXML, but I think it has been deprecated: http://msdn.microsoft.com/en-us/library/aa226559%28v=SQL.80%29.aspx
This was effectively a pre-built, and relatively open, web service - so I'm not sure this counts as a direct connection.
You could also check out http://odbcrouter.com/Main
i have only very limited exposure with .net 1.1 and a bit of 2.0, so i'm actually pretty excited and confused with the many changes that they have in .net 3.5. so i have this access database but we don't want the other programs from calling into this database directly. so i'm writing a wrapper exe which will contains functions which can be call by the other program to return data (ala web service style).
so for now i have manage to create a console app, encrypted the connection string and pull some data from the database.
how do i make it so that the other programs can call this exe's function?
how do i return the appropriate data to the calling program?
and is there's something wrong or a
better design for my case?
i would love to learn from any dot net guys here :)
thanks.
Why don't you use existing Data Access Layer technology to encapsulate the call to Access database?
I used Strongly typed datasets for Microsoft Access database before. And you can use NHibernate, too.