I created a WCF project using the IIS model. I then created unit tests which reference services from that project. Now when I start the unit test, the service is not hosted and thus I get EndpointNotFoundExceptions. When I simply hit F5 everything works fine and the IIS Express comes up in tray.
I checked the option "Always start when debugging" in the property-pane of the service-project and it is set to true.
A Unit Test is a unit test. If you need another process for it (namely some IIS or other web server) it's no longer a closed unit. If you want to test your service when it's hosted, I'd suggest you host it in your test yourself. Check self-hosting services. Then you have control about what class is hosted when and where. For example, you may want a different URL for your unit test and you may want to inject a different data layer so your tests don't need anything outside your unit, like a database.
You are not doing unit testing, and you are actually doing integration testing, since your test suit has no direct knowledge/binding of the service codes and it is just a client program of the service.
Both unit testing and integration testing contribute to good QA. Generally you should create unit testing which directly test the service codes through in process binding interfaces, and make sure it has comprehensive code coverage.
Then create integration testing using MS Test, NUnit or xUnit as test harness, in order to test some run time behaviors of the service.
What puzzle you is that how to make the test suit in the same VS sln run while the service should be running in debug mode. There could be a few solutions:
Build the test suit using Nunit or xUnit, then run the test suit outside VS IDE which is running the service in Debug mode. Actually MS Test could support as well, but only in command line mode.
Host the service in IIS, and you have a batch files to copy assemblies and web.config to there upon every update. Then attach the service codes with respective w3wp.exe instance.
If you just want to test rather than debug, there could be another solution: Use IIS Express. You use either C# codes or batch file to launch IIS Express with the service during tearing up, and close IIS Express when tearing down.
I am building a client-server application, this is all running locally on my computer whilst I am developing the system. However, eventually I would like to deploy the server-side part of the application to a server to run 24/7, enabling client applications to connect and consume the service at will. What I would like to know is, when I come to doing this would I simply just install the server-side application on the server, hit run and that's it? That just seems... well not right (to me), is this the way it is done? or is there a lot more to it? I imagine there is, but I can't seem to find any content on this subject.
FYI - the server is a self hosted WCF application.
You'd want to take your program's executable, support dlls and config files and drop them into a folder. Then create a Windows Service to run the program; if you don't use a Windows Service, the program will only run while you're logged on, which isn't good. As a Windows Service, a reboot of the server will bring the program back online even if you're not logged on.
Here's a knowledge base article from MS on how to make a windows service.
http://support.microsoft.com/kb/251192
If you're program is compiled as a DLL, then create a small .exe program to run it (a wrapper) then deploy the program as described in the article.
Good luck.
I want VS to deploy the latest version of the WCF every time I run my tests.
Currently I have to deploy manually, or run the WCF Service, for it to be deployed.
I'm looking for a functionality similar to starting multiple projects when debugging.
Maybe to specify the behaviour I am missing right now. I can not set breakpoints inside the webservice, as it's not run in debug-mode.
#codespike Using standard unit testing in VS2012
#codespike With Deploy I mean "copy latest version to local IIS, so it can be respond
to calls over the web.
#mayo Yes! that is a brilliant suggestion. Bypassing the Coding and Decoding (webtransport) phase, and go straight to the classes that manipulate the data.
I've got 2 vb.net solutions. One running my client-side code (which runs a Windows mobile application) the other is running my server side code. How can I debug my server-side code (a service) that exists in an entirely different solution?
From where? If from client code, run your server solution (sln) (via f5), then attach to the host via Debug/Attach to Process in the client sln. Alternatively, You could run both SLN at the same time then but break point in the server.
I have several different c# worker applications that run various continuous tasks: sending emails from queue, importing new orders from website database to orders database, making database backups and restores, running data processing for OLTP -> OLAP, and other related tasks. Before, I released these as windows services, but currently I release them as regular console applications. They are all based on a common task runner framework I created, and I am happy with that, however I am not sure what is the best way to deploy these types of applications. I like the console version because it is quick and easy, and it is possible to quickly see program activity and output. The downside is that the worker computer has several console screens running and it gets messy. On the other hand the service method seems to take to long to deploy and I have to go through event logs to see messages. What are some experiences/comments on this?
I like the console app approach. I typically have things set up so I can pass a switch like -unattended that suppresses the console screen.
Windows Service would be a good choice, it runs in the background no matter if you close current session, also you can configure it to start automatically after windows restart when performing a patches update on the server. You can log important messages to event viewer or database table.
For a thing like this, the standard way of doing it is with Windows services. You want the service to run on the network account so it won't require a logged in user.
I worked on something a few years ago that had similar issues. Logically I needed a service, but sometimes I needed to see what was going on and generally I wanted a history. So I developed a service which did the work, any time it wanted to log, it called to it's subscribers (implemented as an observer pattern).
The service registered it's own data logger (writing to a database) and at run time, the user could run a GUI which connected to the service using remoting to become a live listener!
I'm going to vote for Windows Services. It's going to get to be a real pain managing those console applications.
Windows Service deployment is easy: after the initial install, you just turn them off and do an XCOPY. No need to run any complicated installers. It's only semi-complicated the first time, and even then it's just
installutil MyApp.exe
Configre the services to run under a domain account for the best security and easiest interop with other machines.
Use a combination of event logs (with Error, Warning, and Information) for important notifications, and just dump verbose logging to a text file.
Why not get the best of all worlds and use something like:
http://topshelf-project.com/
It will allow you to run your program as command line or a windows service.
I'm not sure if this applies to your applications or not, but when I have some console applications that are not dependent on user input or they are the kind of applications that just do their job and quit, I run such programs on a virtual server, this way I don't see a screen popping up when I'm working, and virtual servers are easy to create and restart.
We regularly use windows services as the background processes. I don't like command-line apps as you need to be logged into the server for them to run. Services run in the background all the time (assuming they're auto-start). They're also trivial to install w/the sc.exe command-line tool that's in windows. I like it better than the bloat-ware that is installutil.exe. Of course installutil does more, but I don't need what it does. I just want to register my service.
We've also created a infrastructure where we have a generic service .exe that loads .DLLs based on an interface definition, so adding a new "service" is as simple as dropping in a new DLL and restarting the service host.
However, we started to move away from services. The problem we have with them is that they lock up the DLLs (for obvious reasons) so it's a pain to upgrade them. We need to stop, upgrade and then restart. Not hard, but additional steps. Instead we're moving to special "pages" in our asp.net apps that run the actual background jobs we need done. There's still a service, but all it does it invoke the asp.net pages so it doesn't lock up any of our DLLs. Then we can replace the DLLs in the asp.net bin directory and normal asp.net rules for app-domain restart kick in.