My WCF service library, the console host for the service, and the client are all in separate Visual Studio solutions. Does this choice of organization impose a problem? I cannot seem to create the client proxy by using the Add Service Reference and Discovery features.
When I run the console hosted WCF service, then change focus to the Visual Studio solution for developing a client, invoke "add service reference" and "discover" it says "no services found in the solution". Do I have to develop the client code inside the same Visual Studio solution as I have developed the host code? That would seem unreasonable.
Having several projects for your WCF solution is a great idea - definitely stick with that!
But you cannot run the WCF host application from within Visual Studio and then use Visual Studio to add the service reference, too, at the same time....
So what you need to do is run the service host application from outside Visual Studio (find the directory, double-click on the EXE to spin up the host) and then you can add the client service reference inside Visual Studio.
In such cases I usually use a single solution file containing all projects across all subsystems + separate solution files for individual subsystems. This allows me to develop the system as a whole, and, at the same time, build individual subsystems separately. This way you can overcome any “editing-time experience” shortcomings, while preserving good separation and independence of subsystems.
Solutions are meant to have multiple projects in them. They are meant to be the level of organization that contains all of the projects you are working on at a time.
No, it's not unreasonable to put all of those related projects into a single solution.
Related
I have one large solution containing 27 WCF services and 3 shared projects (DAL, Models, and Core).
Lets say something critical in the DAL changes. Now I need to publish all 27 WCF services. I am currently doing this manually by right clicking on each of the 27 and choosing publish. I have set up publish profiles on each of the services using "File System" as the publish method. As you can imagine this is quite a pain.
I have created different solution configurations and web.config transforms as well. This allows me to publish to production and the test box with different config contents. Going back to the original issue, when something low level changes in the DAL and I need to re-publish 27 times, I actually re-publish 54 times, 27 to the test box and then 27 to the live box.
How can you publish multiple WCF services or what are best practices for doing something like this? I'm using VS2013 and TFS2013.
FYI - we are currently installing and reading about the new release management tools for VS/TFS 2013.
Thanks in advance.
New Release Management tools for VS/TFS is the way forward. You can create one component for each web service in Release Management tool and use IIS related activities inside the each
component.
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.
Im required to write a Silverlight application using WCF.
I'm also required to use Dependency Injection to gain access to this service in another library.
(I add a Silverlight enabled WCF Service)
The problem is in trying to use Dependency Injection (Prism/MEF in this case). When I make a Silverlight Shared library that will have interfaces for this service, I cannot add this library in the ASP.Net project due to the fact that it is Silverlight library. If I make a non-Silverlight library I cannot add that library to other projects to share that common interface.
Basically I need a library I think to share between projects in Silverlight so I can do this service injection.
Any information is appreciated
As slugster said - this done via linking to windows library files from silverlight library.
You do it as described here: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/01/20/linking-files-in-visual-studio.aspx
I just wanted to add.. Since you go there - what you need is another Framework/Technology. Usually those classes you talking about depend on other classes/namespaces that live in windows only or silverlight only world. And then you need to transfer object data via wire.
Microsoft's solution to this - RIA Services. What it does - it takes your Windows classes and generates proxy classes on Silverlight side. Kind of what you need. And it works with WCF services.
There is 3rd party solutions like CSLA and DevForce.
I use DevForce and it does many things automatically, but instead of generating proxy classes - it creates links just like what you want.
Whether you realise it or not, your question is a duplicate of this one: Shared data object between WCF service and Silverlight app While not asked the same way, the answer is the same.
You need to create a separate project, and share the code files (as links) from one project to the other. Your problem is that the Silverlight project is compiled for a different runtime to the ASP.NET/WCF project. Because they cannot reference a common library, linking the shared files as mentioned is the easiest way to share code between the two projects targetting different runtimes.
I need to debug a Sharepoint WCF service that is deployed for Sharepoint 2010. However, a colleague needs to debug another Sharepoint service deployed on the same phyical machine. If we debug at the same time strange things occur with the Visual Studio debugger. For example, his debugger would break at breakpoints I have set, or I am seeing exceptions raised by his code. Mind you, we are debugging different services in different solutions. From the information I have gathered so far, this behaviour is like this because there is only one w3wp process per application pool that both the Visual Studio Debugger instances attach to.
So I figured I should try running my service in another applicaion pool to get a different w3wp.exe to attach to. Here is what I tried, but I am not sure, if what I attempted makes any sense, please clarify:
IIS Manager shows that there are two different Sharepoint application pools (excluding the one for Central Adminisitration) and a Site for each. So I tried deploying my service using the other application pool by setting the deployment location to the URL of the other site. However the virtual _vti_bin directory of the service still maps to the same physical directory ...\Web Server Extensions\14\ISAPI\. Deploying from Visual Studio works, but getting a ServiceReference does not. Trying to open <url>/_vti_bin/MyService.svc/MEX shows an error page telling me that therer is already a binding instance associated to the URL. So, I guess this is either not the way to do this, or it is simply not possible to "isolate" services in this way. I am very hesitant to just trial-and-error with IIS Manager or Sharepoint Central Administration settings, because I feel I don't know enough to avoid screwing things up.
Could someone tell me how I can solve this?
The URL you specify when deploying in Visual Studio can be misleading. If you have a sandboxed solution, it gets deployed to this location. If you have a farm solution, it gets deployed centrally and it uses the URL to figure out what application pool to recycle. If you have web application specific settings in the solution i.e. safecontrols), these will be applied to the web application hosting the URL.
The _vti_bin is available to every site in the whole farm; as is _layouts. Since a service will be exposed through multiple URL's (one for each site) the SharePoint team has created custom factory classes to make this possible. Check out one of the built in svc files, and you will see that it uses a special factory class. Use this in your svc file to expose your service in all sites.
As for the debugging, it's never a good idea to have multiple developers using the same machine. If you really want to do it, I suggest using two web applications with different application pools. That way each developer has their own process to attach to. If you use different accounts for the application pool, it makes it easier to find the correct one in the 'attach process' dialog.
I am in the process of setting up some IIS hosted WCF projects for continuous integration and am stuck trying to find the best and simplest way to get deployment automated.
Right now, I have the build and deploy working with CC.NET, MSBUILD and a batch file that copies the necessary files to the deployment folder, but I think there must be a better way.
Ideally, I'd like something like web deployment projects, but for WCF.
I would settle for a nice Power Shell script to copy all the necessary files and exclude all the fluff.
Well, there isn't anything stopping you from using a web deployment project for hosting your WCF class library. The SVC file will be picked up by IIS and routed appropriately. We use a standard deployment project and a custom action to create the IIS vroot so that we have a finer control over the settings but a standard web deployment project will do the job as well.
Unless you are running under IIS7 then as far as IIS is concerned it's just standard content that has it's own handler. When you get to Windows 2008 / Windows 7 Beta then things can change a bit as those versions have a very different handler model.
I've found this post to be really helpful: http://msdn.microsoft.com/en-us/library/bb332338.aspx
This depends very much on the technologies you are using. On a previous project, we used TFS, with Team Build. The result was that the WCF projects were built into a folder structure that matched their deployment structure. Additional tasks in the MSBUILD script triggered a deployment script (written in PERL, I think). This took care of all deployment tasks, from deleting old folders, creating the new, creating databases and populating with reference data, then deploying the service and web sites, and finally running Installation Verification scripts and publishing the results to a web site.
On the other hand, if all you've got is a hammer, then hammer away.