I recently made some reference additions to a project in my solution and made some changes to the web.config in order to use another WCF service from within my code without using the 'Add Service Reference' wizard in order to prevent the need to keep updating the reference in case it changes. Since doing this SOAP UI no longer triggers a break point in my service when I use it to test my code responses. It used to work perfectly. What could I have changed that has caused this behaviour?
You can configure what to be started and debugging manually.
Right click on your solution
Properties -> Startup Projects
Check Multiple start-up projects
Action -> Start for your GUI and WCF projects
That will make debugger to attach to these processes and enable break-points.
Related
I have a MVC project solution and a separate API project solution (because it is used by different other solutions).
During debugging is it possible to hit the API solution code on debugging?
Both solutions are obviously running, giving correct data and results, the issue is that I am unable to hit the API project code during debugging - the debugger skips over the API and hits only the main solution.
EDIT
I realised that the API is a separate package and is referenced in the main solution as an assembly so I am not sure if it is possible to hit the breakpoint there at all? It's not used via Ajax.
yeah it is possible.
Assuming you use Visual Studio, start a second instance and attach it to the running process of the API. Put a breakpoint in your API and do whatever you need on the MVC side, to hit the correct endpoint in the API. Execution will stop and you can now debug in the second project as well.
This all depends how you run the API, you can even run the API from Visual Studio, using IIS Express in which case your URL will look something like http:\\localhost\api\sbla\bla:50310 for example.
Attaching works very well when the API is run outside of Visual Studio in proper IIS.
Make sure you tick the box which says "Show all processes" and look for a process called w3wp I think, this is all from memory.
You can't debug the API from the MVC project as they are both running under different processes
------ added after extra info ----
if the API stuff is inside a dll then make sure that dll is built in debug mode and then you can step into it. put a break point inside your MVC code right before you have a call which goes into the dll, then step into it and continue from there with normal debugging
Yes, it is possible.
Just open both your solutions in visual studio. Build the API project and add its dll to MVC project. Put break point on your API and run the API project. Now run your MVC project. Hit the API from your MVC project and break point will surely hit in API.
I created a WCF Service Application project in VS 2012. Implmenented the service.
here is what it looks like:
Now I have a fundamental issue to deal with. I created a new Test project to create more TDD and also some TAD tests. The TAD (Tests after Implementation) tests will test the service implementation while my TDD test will test reliant on mocking my WCF Servcie Interface.
But now going back to my TAD tests which need to test using an implementation of the service. I take that is I'm adding a service reference and using the clientProxy in my unit tests for TAD.
So I add a service reference to a new C# Project. I then continue to create some tests such as:
[TestMethod]
public void Get_CalledViaClientProxy_ReturnsNonNullList()
{
var serviceClient = new CarsClient();
// Act
Cars[] events = serviceClient.Get();
// Assert
Assert.IsNotNull(events);
}
When I run this it fails because the actual service is not running. So what I've done is go back to the actual Service WCF project, right-click the service (.svc) and choose to open it in the browser which will also start the service under IIS Express. Then my tests run fine.
So from that, how do I make this more automated. If another dev downloads this code, those tests should run and the service should somehow be started. I tried to set my service project as the startup project but all that does is opens the browser to show me the file system for that project.
How do people run the service for testing other than in IIS? and make it so it just works for devs? If I can't get my service to run simply but pressing F5 somehow and still able to go back into my tests project to try and run unit tests then this is pointless.
When I simply try to set my "WCF Service Application" project to be the startup project, instead of just starting the service and sitting there with a console window, it opens a web page for the service. Do I have the wrong WCF project type? I noticed that I have a web tab because I've got a "Serviced Application" project, should I be using something else if I want to simply start up my project in VS and continue coding in other projects that utilize this running service?
At a previous company I was at, we all put a "-d" in the WCF service project which when you ran the project it would start the service and a console window would run and just sit there, then you knew the service was running while you continued on writing TAD unit tests against it
e.g.:
however again, my WCF project is a "WCF Application Service" so I don't have that exact debug tab in mine so not sure what to do and then how we were able to have this format of tabs in the WCF service at other places I've been. Maybe it's just a plain C# project, not a WCF project where we were putting the -d but then how was it starting the WCF service if that was the case? Not sure if it was a plain vanilla C# project that we put that -d in but I sure do not have this same tab format in my WCF Service Application project.
Update #2
Ok I just to see the diff, added a "WCF Service Library" project along side my "WCF Service Application" project. The tab now has that debug and now when I launch it it does start the service and the test client comes up because the VS template automatically has /client:"WcfTestClient.exe" in for the command line properties of the debug tab in the project properties.
Since this service is going to serve as a service API that will be used cross applications, maybe I shouldn't be using a "WCF Service Application" and should be using a "WCF Service Library" type of WCF project template.
Refer your wcf project from the same solution as your test project.
Right click solution -> set startup projects
choose multiple startup projects and change the action of your wcfservice from none to start or start without debugging. Play and test :)
Or start project without debugging, wcf service will be running and you can continue coding/building and testing.
EDIT:
Here is what you also could do;
Change your wcf project to wcf service library, make sure this project have the following config...
under debug:
Start action: Start project
Start options: command line arguments: /client:"WcfTestClient.exe"
under wcf options:
Check "start wcf service host when debugging another project in the same solution"
Under solution -> startup projects, make sure you have a single startup project.
This way you can debug your other projects in the solution, visual studio will ensure that your wcf service is started.
You can host your service in local IIS automatically by configuring project settings from Visual Studio. Then whenever you compile your WCF service, IIS hosted instance will be updated and ready to serve automatically.
Right click your WCF Service project -> Properties -> Web -> Use Local IIS Web Server and click Create Virtual Directory. Before, do not forget to turn on your IIS services feature on your machine if not.
Additionally, why dont you test your concrete service implementation only just by referencing it, you dont need to run a service and connect it to test your business.
Usually you put WCF service logic in some other project, let say "WCF Login Library" and you test functions on that. You don't need wcf service to test those method calls. You can then use only one method to test the connection with WCF (that's usually done manually by me).
Isn't that simpler approach?
I have created an application which has a client (WPF) and the Server (WCF), the service is IIS hosted, currently I am having to have 2 versions of vs 2010. One loads the wcf service in IIS and the other in my windows application.
The problem with this is it takes so much resources.
It appears if the wcf service is "NOT" hosted in IIS then I can start two projects at the same time according to this http://msdn.microsoft.com/en-us/library/bb157685.aspx
But what are my other options?
I need to find the best way of being able to compile / run the 2 projects and able STEP INTO each when when in debug, without using too many resources or having more than one vs 2010 open at the same time.
You should be able to debug both from the same instance of Visual Studio if they are in the same solution. When you run your application from Visual Studio, open the Debug menu and choose Attach To Process, you need to attach the debugger to the ASP.NET worker process (aspnet_wp.exe), it should automatically attach to your client.
Open service and client code in VS. Open Debug menu. Attach to process. Hold the Ctrl key and select as many processes as you want to debug using Mouse click.
In your case, you can select the ASP NET worker process depending on the version of IIS and the client process.
The easiest way to debug your WCF service is to:
Right click on project containing svc file.
Select Set as Startup project.
Put a breakpoint on the methods you want to debug.
Breakpoint should be Red.
Make sure your app config file is pointing to the debug WCF service version that's currently running, ex:
http://localhost:12345/MyService.svc
Run your app.
When the app calls that WCF method, it should stop on breakpoint.
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.Assembly.GetTypes()
at Microsoft.Tools.SvcHost.ServiceHostHelper.LoadServiceAssembly(String svcAssemblyPath)
How can I loop through LoaderExceptions property to see what errors have occured as it is not hitting any service and give me this error before it runs any code?
Thanks
I managed to fix the problem. One of my project was set to x86 and others were set to Any CPU. Changing all to Any CPU fixed the problem for me.
Thanks
The solution was different for me. This may be obvious information to people who are even passingly familiar with WCF development. But in the hopes that it will help other novices struggling with the same problem, here is what I figured out.
It turned out the app I was debugging didn't need WcfSvcHost.exe at all. WcfSvcHost.exe is for self-hosted WCF applications. This app used services exposed as an endpoint on a web application.
What finally clued me in to this was this: First, this screen would show up:
I noticed this shows up as a separate process for WcfSvcHost.exe in the Windows Task Manager. This explained why I couldn't get the debugger to break even when I adjusted Exception Settings to break when System.Reflection.ReflectionTypeLoadException was thrown. Visual Studio wasn't breaking because it was not attached to the WcfSvcHost.exe process. It was attached to the IISExpress.exe process that was running my app. But the WcfSvcHost.exe process was throwing the exception.
When I clicked the OK button on the error message above, the WcfSvcHost.exe process would exit and no longer appear in Task Manager. But the app was still running fine. So clearly whatever is happening isn't needed. A quick check with another developer confirmed that the app didn't require self-hosted WCF services.
For some reason, Visual Studio was starting WcfSvcHost.exe anyway. And that finally led me to this answer. WCF class library projects can be configured to launch WcfSvcHost.exe whenever debugging starts.
The answer is to right-click on each WCF class library project, choose Properties, and click on the "WCF Options" tab. Then uncheck Start WCF Service Host when debugging another project in the same solution.
You must do this for all WCF class libraries in your solution. I wasn't sure which ones were which, so I just looked at the Properties for each class library and fixed the ones that had the WCF Options tab.
I have an application that hosts several WCF services. I have created a custom ServiceAuthorizationManager that is working perfectly. I inspect a few elements on the OperationContext.IncomingMessageHeaders to get a username and password. This was to overcome some limitations in our environment that wouldnt allow us to use what was built into the platform. the manager creates a custom IPrincpal, with a few necessary custom objects in it, and places it on the currently running thread, for use later in the WCF business logic. this is Working great.
Problem is that I have a WCF service that is a workflow, and I need to use the same mechanism there. The Manager is being called correctly, however when executing the Thread's currentPrincpal isn't my custom principal, it's a genericprincipal. Investigation shows that the workflow runtime is creating a thread, and not using the thread that the WCF call came in on.
Has anyone run into this issue, and are there any good solutions to it?
If the runtime is in the same appdomain as the manager then you should be able to call
AppDomain.CurrentDomain.SetThreadPrincipal
See here for more information