I would like to create a c# dll that handles requests. I would like the requests to come as webservice calls so that websites can quickly call the dll. Is there a way to integrate the two - to have the code for the webservice be placed inside of the dll?
Or, if the webservice has to be separate - is there a way with visual studio to put the webservice into the project with the dll but tell the compiler to compile it as an external file? That way this would at least help me keep my project structure simple and clean.
It's unclear to me what you're really trying to do. "A DLL that services requests" can be implemented in any number of ways.
One way to implement a Web service in a DLL would be to use an HttpListener.
You'll have to supply more information about what exactly you're trying to do before we can provide reasonable answers.
All you need to do is create a new WCF Service Project. This will cause your services to be created as a separate application under IIS. Both projects would be in the same solution.
Related
I currently have an asp.net console application which simply retrieves a lot of data via an API from a remote server and, using Entity Framework, saves it into an SQL database. The application takes 3-4 days to run and I run it manually once a month or so.
The project is separated into a Models class, and a Repository class as well as the application itself.
I need to now build an ASP.NET MVC web application which allows users to view the data that has been retrieved and am looking for advice on how best to structure this.
Do I create a new ASP.NET MVC project in my solution and set that as the start up application, referencing the same Models and Repository classes? If so, how do I then run my console app? Or is it best to keep these as separate solutions, just referencing the same database?
Is there a better way of doing this as well? (ie, is there some way the console application can be rebuilt as being part of the front end and use queues or workers to fetch the data regularly?)
Thanks for your help,
Robbie.
Same solution. Different projects. By being in the same solution you gain the easy ability to reference shared components. I would actually recommend breaking out your entities, repositories, etc. into a third project, a class library, that then both your console app and MVC app will reference.
If you don't put everything in the same solution, then you're either stuck in DLL hell, where you have to build your project and manually copy the DLL into the other project, add the reference, and then keep everything up to date when you make changes in that DLL. The more projects that get involved, the greater the entropy and greater the likelihood that your projects all end up running on different versions of the DLL.
Another option is to create a Nuget package containing the shared components, host it in your own private repo, and then add it to each project that needs it. However, while it's pretty easy to set all this up, it's not 100% frictionless, and you will have to remember to repackage and republish the Nuget whenever you make changes, and then individually update the package in each referencing project.
Long and short, same solution is always the best way to go unless there's a very good reason not to. It's the only "it just works" approach.
Personally I would keep these as separate projects and separate solutions that just reference the same database, but move code that can be shared by both solutions into a separate class library.
The way your web application will present your modeled the data will most likely be very different to how your console application will use it; so using the same models and repositories will most likely further couple your web application to your console application.
This is very similar to the way micro services work, where the micro service acts and grows independent of its consumers (in this instance, your web application) and only communicate via a clearly defined API.
I want to make a call to a web service that is written in C#, through Visual C++ or C++ in Visual Studio 2010. I searched on web but was not able to find any point to point document. It would be a great help if you will tell me.
If you're prepared to go with managed C++ then you can use WCF.
However, if this isn't an option then your best bet is to go with a socket approach. You'll need some cross-language way to represent the data your sending from C++ to C# and back again. Google Protobuf will help here as there are frameworks for both languages, in addition to many others.
A web service uses something JSON or XML as an interface and is inherently language independent. You would have to look for libraries that can create requests to the web service. For example if your web service in C# uses SOAP (XML) which it would if you created the default web service in Visual Studio you could create your own request in XML in accordance to the specifications of SOAP:
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
or use one of the libraries mentioned in this question:
Generic WebService (SOAP) client library for C++
Have a look at Walkthrough: Accessing an XML Web Service Using C++.
Does anyone know how to do this? I built a backend c# class in asp.net but want to access these same classes without recreating them in silverlight. Is this a possibility?
You can reuse the cs files by adding them to your project AS LINK. Right click in your project and select Add Existing...Browse to your file and in the Open Button, use the pulldown arrow on the right to select Add As Link. You will see the file added to your project with an icon that with the little Windows Shortcut icon overlayed on it.
Just remember - the ASP.Net runs on the .Net runtime. Silverlight runs on the CoreCLR (Silverlight runtime.) Not everything that compiles in oone will compile in the other...
To separate things a little bit, #if directives can help, you can also use Partial Classes and partial methods (to add content that only runs on the server or on the client.)
RIA Services is definitely the way to go for sharing code between ASP.Net and Silverlight.
As well as the previously mentioned generation of domain service models, it also lets you share individual files between the web-app and Silverlight by simply inserting "shared" in to the filenames. e.g. "MyClass.shared.cs".
RIA services does not take long to get to terms with (and there are good tutorials about). Try this one.
Well, ASP.NET itself isn't going to work (ditto many of the full libraries), but I'm assuming you just mean you local domain model etc.
IIRC you can try to simply reference it, but it may well generate a warning message. Of course you need to be exceptionally careful not to use anything that the other platform doesn't support...
IMO, the better option here is to create a second csproj that includes the same .cs files (or cheat with a wildcard/deep include). And build both. Same C#, different dll/platform.
Is isn't uncommon to find that you need a very small usage of #if directives, too.
WCF RIA Services may help you solve your problem. Silverlight does not use the same runtime as ASP.Net does and you cannot directly share assemblies containing model classes on the client and the server side. To solve that WCF RIA Services will transparently generate classes on the client side based on model classes on the server side. Obviously WCF RIA Services will also allow you to create, read, update and delete objects of these classes using a web service.
MSDN has more specific information about WCF RIA Services Client Code Generation.
I have some VBA code that needs to talk to a running c# application.
For what it's worth, the c# application runs as a service, and exposes an interface via .net remoting.
I posted a question regarding a specific problem I'm having already (From VB6 to .net via COM and Remoting...What a mess!) but I think I may have my structure all wrong...
So I'm taking a step back - what's the best way to go about doing this?
One thing that's worth taking into account is that I want to call into the running application - not just call a precompiled DLL...
In the past, one way I accomplished something similar was with Microsoft Message Queueing. Both languages/platforms can read/write to a queue.
In my scenario, we had a legacy Access database that we had to maintain. We wanted to migrate away from it and replace it with a more robust .NET solution. To get real time data out of the current system into the new system, we added VBA code to write data to a message queue. Then we wrote a C# windows service to process that data in the new system.
I'm not entirely sure of what you're doing, so this may not be a fit, but I thought I'd mention it.
I've come up with a solution using my original structure...
That is, the VBA application calls a COM wrapper application that translates all of the types from .Net to COM safe types. This wrapper then calls the main service using .net remoting.
The problem I was having was that the common dlls between the wrapper and the service needed to be in the C:\Program Files\Microsoft Office\Office12 folder (along side msaccess.exe).
While I was using the AssemblyResolve method to provide the dlls at runtime, this wasn't working...So for now I'll just have to have the dlls copied to the folder - a far from elegant solution, but at least the communication is working for now.
I've written a console app that sends MS Reports to emails.. (the reason was that i could check it easily if it works)
I want this to run daily at 6 am.
My idea was to write a service (so nooone will need to be logged in and the service will run).
So I'd like to call the static Method directly in a WebService.
I've a solution with 1 project file that is my console application (with settings, many references.. etc). I'd like to add another project - Windows Service.
My question is.. how to do that easily, so I wouldn't have to copy all classes etc to the Windows Service project?
Or am I totaly off the way? :)
Thank you!
Sounds like overkill to use a Windows Service to send an email once a day. Why not just schedule a task in Task Scheduler?
You're going to have to refactor your app. I'd recommend three projects -
Console App - instantiates and performs any neccessary set up on your business logic object then routes all output to the console. Use this for debugging and testing
Business logic - Extract all the logic of your application into this class.
Service - Basically the same as the console app except that I would recommend sending any errors to the global event logger. That way if your service bombs you can find out why.
You can use this pattern for any other services you develop.
Create a class library and put the shared classes in that library.