How can I use the debug a service within Visual Studio 2010? What I would like to do is step thru the code as the request is being processed.
I am running the service by right clicking on the web site project (C:...\APIServiceSite) within the solution and selecting "View in Browser". Everything runs OK and I get the expected results back from the service but I cannot find a way to step thru the code which is in a another project (APIService) within the same solution.
Off the top of my head: Right click the service project and choose Debug >> Start New Instance. Then start the debug on your web "test" application. You should now be able to accomplish what you desire. (since this is off the top of my head, if it fails, it is very close to the right answer).
A better option is to move the functionality into a class library and make the web service project very thin (essentially returning calls from the class library assembly). You can then test the business functionality by using a unit test library, like MSTest (built in with most team system SKUs of Visual Studio) or nUnit (etc). Sure the tests will likely be integration tests, but you accomplish two good things:
You get the UI out of the testing equation so you can focus on the business logic
You create repeatable tests (think science, not art)
I find it a really bad pattern to have moving parts in a UI project, unless the moving parts are focused on presentation of data. And, yes, I see web services as a UI, even though the user is an application rather than a human body.
I debug a service by making a standard wpf application that uses it. By adding Existing item / Add as link all source file from the service into a new project (wpf application), into a separate folder of this application. So i can test it, and debug the same way i test/debug an application.
Note that you might use the microsoft log service to log issues that your service may have when running as a service. For handling the errors, i made one MustOverload (in vb) function that handle errors, and i overload it as a MessageBox when using the service in my test app, and overload it as ms log when it runs as service
(quick info on log here :
http://msdn.microsoft.com/en-us/library/aa984385(v=VS.71).aspx
)
Related
I would like to create a headless test library for unittesting my Universal Windows Platform App. I know that Visual Studio offers a test app, but this comes with a head and executable, rather than a headless library.
Even XUnit says to create this test app which again has a head to it.
http://xunit.github.io/docs/getting-started-uwp.html
The only alternative I have found is to use a PCL To expose some of the functionality to a standard test class, but this is really non-ideal as it limits what I can test to be non-uwp functionality.
Any recommendations?
Comparing with the desktop app, the Windows Runtime App was running on the app container (an isolated process with low integrity).
The unit-test for UWP app is running on a blank UWP App (to ensure the test library is also running on the app container). Since the traditional test loader is running on a normal process, I’m afraid we cannot create a headless unit-test library for UWP app which can run on a normal process.
I had a similar challenge. While I was unable to test headlessly, what I did was to separate out the business logic from classes that refenced uwp classes (e.g. Windows.). I ensured that the business logic contained only C# standard classes (sometimes, i did have to to map some classes to more common dotnet core classes, like using a Hashtable for my resources instead of Windows.ApplicationModel.Resources). The Hashtable became my interface for passing resources around, and I have one (admittedly untested) class that maps them back and forth.
Once I did that, i created a regular headless dotnet core unit test using Microsoft.VisualStudio.TestTools.UnitTesting.
The unit test project file has all the classes i wanted to test (as links) as well as the unit tests themselves. By doing things this way, I'm able to test all the business logic. The only thing that does NOT get tested is the UWP-specific stuff (In my case its just gui code, and a few mapping classes). You can use a variety of techniques (abstract interfaces/MVVM/delegates, etc) to ensure the callback to your GUI gets CALLED, you just can't test that very upper layer.
Its not perfect, but it does provide for testing a significant portion of your app. If you have the GUI just for display, and put all the logic into a class that CAN be tested, it will make for a very small amount of code that is not tested.
i have a WCF web service that i'm working on. currently every time i'm changing the contracts in my service at the server side, i need to both update the service reference and regenerate the proxy object used by the client with "svcutil.exe". is there anyway to do both automatically? i once saw someone who generated the client inside the reference.cs file but i have no idea how he did that. I'm using visual studio 2010.
so far all i have found was different msdn references telling me to use the svcutil. its not intuitive and usually i can find easier solutions than cmd when working with VS.
If you want to automate your development work, learn command line and svcutil.exe.
You should use svctuil.exe to generate wsdl and proxy classes which go into a project called something like "MyService.ClientApi". To make thing easier, used a batch file to be called in the build event of the service project.
For more details, please read http://www.codeproject.com/Articles/627240/WCF-for-the-Real-World-Not-Hello-World
After reading this CodeProject article, you should be able to create respective batch files, and call them in the build events.
And you will see the beauty of separating contracts and implementation into 2 projects.
Say, you will have
MyServiceContracts.csproj with CreateWsdl.bat to be called in the post build events
MyServiceImp.csproj
MyServiceClientApi.csproj with CreateProxy.bat
You can make CreateWsdl.bat call CreateProxy.bat. So everytime you make changes in the contracts, you will have new Wsdl/XSD file to be published, and new MyServiceClientApi.dll to be used by all client programs.
You can right click the "Service References" in your Visual Studio project and select "Update service reference". This will update your proxy class and the configuration file.
If you are willing to forgo the use of auto generation, you can construct your service contracts classes manually (go ahead and use reference.cs as a starting point) and then build as a separate assembly that can be shared between the client and server. Propagation of any later change will then happen automatically as you want whenever the contracts assembly is rebuilt.
Solved. Apparently i had to uncheck the reuse types in reference assemblies checkbox, and there was no more difference between the file generated by svcutil and the reference.cs file. I want to blame Microsoft but it really makes sense. Damn. Thanks a lot everyone
I want to be able to develop a windows service which is capable of running multiple instances each with different parameters.
Ideally I want to be able to maintain these parameters in a browser based control panel.
I have written a control panel in C# which saves the config data to an XML file.
From this I want to be able to configure the number of services to run, and what their parameters should be.
I want to be able to dynamically add and remove instances of the service as required.
My questions are:
1) Is this even possible?
2) Can I start a service with specific properties, from the control panel? (Maybe by using "NET START" with command line parameters?
[Edit]
I just saw something online regarding the ServiceController class; can this be used to add and remove instances of a service as well as start/stop services?
[/Edit]
Thanks for any help
Edit: My initial answer was factually wrong.
You can use command line parameters, either with NET START (which however will only accept parameters starting with a backslash) or with SC START (which will accept anything as a parameter).
You cannot start a service with dynamically chosen command line parameters. Parameters can also be specified at service registration time, in which case they remain constant thereafter.
However, starting multiple instances of a service sounds like the wrong idea. There is nothing stopping you from making just one instance of the service that you configure at runtime by communicating with it (e.g. with ServiceController.ExecuteCommand), which is what you should do IMHO.
To communicate with a service, see for example How to communicate with a windows service from an application that interacts with the desktop? and How to create and communicate with a C++ Windows Service in Visual Studio 2010?
I'm working with this small web application (1 page) built by someone else that does a specific task after pressing a button on the web page.
Now the requirements have changed slightly, and we need to automate this to run weekly without the need of user interaction.
What would be the best way of doing this, minimizing the changes done to the code?
I was thinking on adding a console app to the project that then references internally the web app but that doesnt seem to work.
Or maybe converting the web app to a to console app, if that is actualy possible?
Is there any straightforward way of doing this?
Thanks
First, make sure the "specific task" is broken out from the Web application so it resides in its own .NET project. Even if this project just contains one class you're "separating concerns" between the Web-based UI and the task itself.
Then you can create another "wrapper project" to call this new project as you wish. A console application might well do the job -- you can run that using a Scheduled Task -- or you may prefer to use a Windows service.
It really depends on how well the existing code is structured. A common approach is to divide business logic from the presentation layer. In VS, it's normally done by creating a class library project and keeping all the business logic in there. A web application project would then just instantiate business logic classes and run their methods.
If it is done like that, you just need to reference the class library project. If, on the other hand, you have all the logic in the web application project, probably there's no fast way of doing that, as you're not supposed to instantiate Page classes manually (well, you can do that as well, but that is clumsy and not recommended).
So in that case, you should create a class library project and move there all the logic you need to use in your console app. I would imagine that would require quite a bit of refactoring.
I am currently programming a ASP.NET MVC3 application, using Entity Framework 4.
There are certain tasks (processing 10K+ of records, for instance) that has to run in the background. I am writing a console application to do the job (and maybe run it as a thread or window service).
Both the console app and MVC3 EF4 project
Since I have written lots of services and model code inside the MVC3 application, I would like to reuse that in my console project.
Is that possible?
(Due to time constraint, I cannot refactor our the services into another DLL/code library)
Moving the services and model code into another DLL shouldn't take more than about 10 minutes, if that. You don't even need to change the namespaces if you don't want to - just create the new project, move the files over, add a reference to the class library from both the console project and the MVC project, and you should be done.
It depends on how you have built the MVC system and which parts you are going to use in your console application.
Eg If you are going to reuse Controller logic in your console app you need to provide fake implementations of numerous classes. Eg HttpContextBase.
Further more if you have use Session, Cache, HttpContext you will have hard time using the code base for the console app.