I want to consume a series of REST services from a provider. But there are a lot of functions I can call and send to the server, so I think it would be a good idea to create a separate library that my C#/MVC2 project can reference and call.
In VS2010, what is the correct project I should select to create this new library? Just plain old "Class library?" It's grouped under "Windows" so I don't know if the correct template to use for a web project.
Thanks.
"Class Library" would be fine. The Class library template is not tied to anyone particular type of project, so they can be used for Web, Console, Windows, Wpf etc.
Of course the functionality you provide in the Class library might be limited to a specific execution evironment because of the functionality you might put into the library, for example if you develop a bunch of functions that expect to be run in an ASP.NET environment then the functionality of the class library might not be applicable to a Console application.
Technically, yes, a "Class library" will give you what you want. Consider, however, whether there are any potential benefits for you in creating a proxy Web Service that you use as an intermediary between your own application(s) and the remote provider. Doing so allows additional management options that can be performed separately from the calling application.
You could also try the MSDN REST Starter Kit. It contains VS templates that help you do all the RESTful things you could ever imagine doing.
Related
We have C# code, which is backend for us. Now we need it to be used in our website which is developed in Drupal.
As far as I know, there is no easy way to do it. You basically have 2 options:
Rewrite the code in php. It may be not possible to do it however, it depends on what the code does.
Expose c# code as an external webservice (e.g. with WCF) and then consume the webservice. Drupal is able to do it - more info.
A sloppy solution would also be to display your C# page in the Drupal page with an iframe. I do also agree with empi's answer to rewrite the code in php or a web service depending on your requirement.
You can build DLL project (class library) in C# and use the DLL as reference back in the drupal project.
Not sure about this, and never done before.
You better research more.
But, the best way to use the .NET code in another application is to build the required code into DLL project and use in whichever language you want to use.
I have Silverlight Application. Getting started with Linq I find out I have to make mapping in a new project in the entire solution. To use generated classes from new project I use "Add Reference". For Silverlight Application it is possible to add reference only to the same kind of Project.
Here I got the problem because in Silverlight Applications it's impossible to right-click on the project Add ->New Item -> LINQ to SQL Classes.
Perhaps entire idea of using classes from different Projects is stupid in this situation... Please help =)
The Silverlight code executes client-side. LINQ to SQL will execute server-side. You need a way to get your LINQ to SQL objects accross the wire to your Silverlight client. The easiest way to do this is with WCF RIA Services http://www.silverlight.net/learn/advanced-techniques/wcf-ria-services/using-wcf-ria-services.
Firstly, you won't be able to use Linq-to-SQL in silverlight, as silverlight will never be able to connect directly to SQLServer. The only way to use Linq-to-SQL with Silverlight would be to create a service on your web server (WCF or something else) that uses L2S. Silverlight will then communicate with the service which in turn will communicate with SQLServer.
An easy way to share code between Silverlight and a non-Silverlight project is to share the files, rather than a binary reference (which is what you are trying to do). Select Project->Add Existing Files... from the original project. That way, the original project will compile in its format, and Silverlight will compile the same code into its format.
You might want to look at WCF RIA Services if you want to do data access from a Silverlight application, it simplifies the process a lot, and generates the services I mentioned above for you.
I would like to know how to allow my C# application to be used from others' own applications.
Is making the relevant classes public enough for this purpose? Shall they be able to put a reference in their projects to my .exe and use my public classes freely? Shall they only be able to use it from .NET applications?
What else should I take into account? Any security issues maybe?
Your .Net dlls can be used by other .Net applications. You can separate the logic part of your code from the interface, and put the logic in "Library" projects that will be compiled as Dll files that can be used in a .Net application by adding references to them.
If you want to allow non .Net apps to used you can use COM Interop:
Wikipedia - COM Interop
COM Interop C# Tutorials
You can also use WCF services as CSharpVJ says.
Create a wrapper WCF service and expose your exe application thru' those WCF services, and it will be available to almost all clients based on even other platforms like Java, Python, Ruby and more depending on which settings you use inside your WCF Service..
WCF provides a service based model to communicate with other applications based on .Net and other platforms.
WCF is explained at this article in MSDN
You could always just make the sourcecode public on https://github.com/ for example.
That would other people allow to view and edit your sourcecode compeltly, which might be even better than a WCF service
I'm hosting a WCF service within an organisation, and I was hoping to build a client into an assembly DLL to package up and give to anyone who wants to consume the service.
I could create a class library and simply add a service reference, build that, and distribute that. Any recommendations on an alternative approach?
I did something similar in my previous organization. I also had the additional requirement that the library should be COM visible so that a legacy C++ application could consume the API.
I went so far as not requesting the client to provide any WCF configuration, beside passing a bunch of parameters through the API (service URL, timeouts, etc...). The WCF was configured programmatically. I was in a very tightly controlled environment, where I exactly knew the clients of the library and could influence their design. This approach worked for me, but as they say your mileage may vary.
At my prior job we always did this. We'd have a library project that contained nothing but a SVCUTIL proxy generation and the config file to go with it.
This way our other projects could utilize this library and we'd only ever have one proxy generation. Great in a SOA model.
In your case you could then distribute this assembly if you wanted. Personally, I find the benefit greater for internal cases you control, but I suppose if you really felt charitable, distributing a .NET version for clients to use would be beneficial.
What's the service host going to be? If it's going to be an HTTP based one, putting it into an ASP.NET app makes a lot of sense. Otherwise, yeah, fire up the class library.
UPDATE based on comment
The client packaging really depends on what the receiver is going to do with it. If you're targeting developers, or existing in-house apps, then the library is a great option (though I'd probably wrap it in an .msi to make the experience familiar for users). If there needs to be UI then obviously you'll want to think about an appropriate UI framework (WPF, Silverlight, WinForms, etc)
I would simply provide a library that contains all the required contracts. That's it - they can write their own client proxy.
Do your users know how to use WCF? If not, include a proxy class that instantiates a channel and calls the service.
I don't really see any point in providing an assembly that just includes code generated by svcutil. Why not just give your users a WSDL and then they can generate that code themselves? Distributing boilerplate doesn't seem like a great idea.
I have an old MFC app written in Visual Studio 6. This will at some point be rewritten in C# .NET. However, before then I have to write a couple of new Windows services for the existing application. The others were written in ATL. What I would prefer to do is write these new services in C# .NET so that when the rest of the application is rewritten, these don't need to be.
Is it going to be possible to call the interfaces on the libraries hosted in a .NET windows service from the old application? If so, could you please explain how.
Absolutely. You're looking for a feature of .NET called COM-Interop.
http://msdn.microsoft.com/en-us/library/kew41ycz%28v=vs.71%29.aspx
http://msdn.microsoft.com/en-us/magazine/cc163494.aspx
The second link has an ATL example.
EDIT:
Based on your feedback in the comments, let me expand on this...
Ah - you're right about the sample on that page.
The first link is really where you want to start for all the details. If you follow the links, you'll find this page:
"Exposing .NET Framework Components to COM"
http://msdn.microsoft.com/en-us/library/zsfww439%28v=vs.71%29.aspx
Essentially, it's just a matter of applying a series of attributes to your classes and properties, and then generating the appropriate registry entries on the client machine (which .NET has a tool to do - see: http://msdn.microsoft.com/en-us/library/bctyca52%28v=vs.71%29.aspx)
I've done this several times myself for .NET projects people needed to call from VC++ and/or VB6.
Some other links that might be of interest:
http://www.codeproject.com/KB/COM/nettocom.aspx <-- Perfect example of what you're trying to do.
http://www.codeproject.com/KB/COM/Universal_CCW.aspx
I've done this exact thing with an MFC-based C++ application in Visual Studio 2008 and a .NET-based C# Windows service.
First, if you have not created the C# Windows services yet, I've got a couple of tutorials for creating the basic framework. The first tutorial provides a step-by-step procedure for creating the service and writing events to an application-specific event log. The second tutorial shows how to modify the service to install and uninstall itself from the command line, which I find of great use.
Second, you need to decide how you are going to communicate between your MFC application and your Windows service. Any kind of inter-process communication (IPC) model will work - sockets, pipes, shared memory, WCF, etc. Since you are wanting to migrate to .NET anyway, I would recommend using Windows Communication Foundation (WCF), which is the way I've done it. Specifically, I chose the named pipe aspect of WCF for my communication method based on the chart shown here.
If you go down the WCF route, you'll benefit from the fact that the communication between application and service is .NET-based. Thus, when you move your application to .NET, the communication mechanism won't have to be rewritten. The trick in the meantime is getting your MFC application to use the WCF code. To do this, write the WCF client code in a .NET assembly using C#. Then, use a C++ dll to bridge the gap between your MFC code and the .NET assembly. I've got another tutorial with step-by-step instructions for how to do this.
Hope this helps.