How do I properly set up a Silverlight-Enabled WCF Service? - vb.net

EDIT: I started a closed vote on this question because I resolved the issue. I was doing everything fine, but a reference to an ASP URL rewriter that I downloaded and uninstalled a while ago still had a reference in IIS. This forum post by Waclaw Stypula (the one with the steps) helped me track this down, by accident. When I launched the run command, IIS told me that it (obviously) could not find the rewriter DLL. I removed the reference and the app ran fine after that.
I am following the silverlight.net tutorials by Jesse Liberty. Currently I am trying to do tutorial three, but I am running into a wall under the heading "CREATE THE WEB SERVICE" (about halfway down).
First, when I create the new service by adding it to the solution, the tutorial indicates that three files should be created; IService1.vb, Service1.svc, and Service1.svc.vb. I do not get the IService1.vb file when I add the service to the solution. I downloaded the copy of the project they provided, and the Service1.svc.vb file is in there, so I added one manually and copied the contents of the file. The tutorial says it is a VB tutorial, but displays C# in the accompanying screenshot so maybe that is the issue.
After I get all the files made up like the tutorials (copy/paste to make sure I don't have a typo), I try to add the service reference and get the following error:
The service class of type KeyboardControl_Web.Service1 both defines a ServiceContract and inherits a ServiceContract from type KeyboardControl_Web.IService1. Contract inheritance can only be used among interface types. If a class is marked with ServiceContractAttribute, it must be the only type in the hierarchy with ServiceContractAttribute. Consider moving the ServiceContractAttribute on type KeyboardControl_Web.IService1 to a separate interface that type KeyboardControl_Web.IService1 implements.
I tried googling different portions of the message, but did not find much useful information.
Here is the code for the different files:
//IService1.vb
Imports System.ServiceModel
' NOTE: If you change the class name "IService1" here, you must also update
' the reference to "IService1" in Web.config.
<ServiceContract()> _
Public Interface IService1
<OperationContract()> _
Function GetAllLocations() As List(Of Address)
End Interface
//Service1.svc.vb
Imports Microsoft.VisualBasic
Imports System
Imports System.Collections.Generic
Imports System.Linq
Imports System.Runtime.Serialization
Imports System.ServiceModel
Imports System.Text
' NOTE: If you change the class name "Service1" here, you must also
' update the reference to "Service1" in Web.config and in the
' associated .svc file.
Public Class Service1
Implements IService1
Public Function GetAllLocations() As List(Of Address) Implements IService1.GetAllLocations
Dim db As New DataClasses1DataContext()
Dim matchingCustomers = From cust In db.userControlDemos Select cust
'Return matchingCustomers.ToList()
End Function
End Class
I am new to Silverlight/WCF in general, as well as to Interfaces and Services. Can you guys help me get on the right track?
EDIT: I should add that I am using Visual Studio 2008, on Windows Vista Business SP1.

if you have the Silverlight Tools for Visual Studio installed, instead of using the default WCF template, consider using the "Silverlight-enabled WCF Service" which simplifies things for you and puts all the required configuration in place. This new template was introduced in Beta 2 and still exist (ref: http://timheuer.com/blog/archive/2008/06/06/changes-to-accessing-services-in-silverlight-2-beta-2.aspx).

Related

RateService not defined with FedEx WSDL in VB.NET

I am using using VB.NET in Visual Studio 2007. I am trying to integrate the FexEd rating service into one of my company's websites using the FedEx WSDL. My connection/integration with the WSDL seems to be working properly as far as I can tell (first time working with WSDLs) since it isn't complaining about undefined methods and such.
The exception to this is that when I try to create a new instance of RateService I get an error
"Type 'Rate Service' is not defined."
I am using the exact same declaration that is in the sample code that FexEx provides Dim service As RateService = New RateService() and have the same import statements.
Can anybody think of a reason why I am having problems with just this one class? Or is there anybody who has used the Fedex service that can give me pointers? Feel free to ask me questions if you need more info since I most likely left out something important.
Thanks in advance.
Here is the beginning of the RateService Constructor asked for by urbanlemur
Imports System.ComponentModel
Imports System.Diagnostics
Imports System.Web.Services
Imports System.Web.Services.Protocols
Imports System.Xml.Serialization
'
' This source code was auto-generated by wsdl, Version=2.0.50727.1432.
'
''' <remarks/>
<System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.1432")> _
<System.Diagnostics.DebuggerStepThroughAttribute> _
<System.ComponentModel.DesignerCategoryAttribute("code")> _
<System.Web.Services.WebServiceBindingAttribute(Name := "RateServiceSoapBinding", [Namespace] := "http://fedex.com/ws/rate/v13")> _
Public Partial Class RateService
Inherits System.Web.Services.Protocols.SoapHttpClientProtocol
Private getRatesOperationCompleted As System.Threading.SendOrPostCallback
''' <remarks/>
Public Sub New()
Just to verify did you create the proxy class? (Sounds like you did but never hurts to ask)
Create web service proxy in Visual Studio from a WSDL file
Do you have the connection defined in your web config?
<applicationSettings>
<RateWebServiceClient.Properties.Settings>
<setting name="RateWebServiceClient_RateServiceWebReference_RateService" serializeAs="String">
<value>##fedex webservice address ##</value>
</setting>
</RateWebServiceClient.Properties.Settings>
</applicationSettings>

Ambiguous reference in WCF and client application

I've managed to reproduce one of the errors in a test project with a similar structure to my production code. It consists of three simple projects:
Common (class library):
namespace Common
{
public enum PrimaryColor
{
Red,
Green,
Blue
};
}
Library (WCF service library), which has a reference to Common:
using Common;
namespace Library
{
[ServiceContract]
public interface ILibrary
{
[OperationContract]
PrimaryColor GetColor();
}
public class Library : ILibrary
{
public PrimaryColor GetColor()
{
return PrimaryColor.Red;
}
}
}
ClientApp (console application), which has a reference to Common, and a service reference to Library called "LibraryServiceReference":
using Common;
using ClientApp.LibraryServiceReference;
namespace ClientApp
{
class Program
{
static void Main(string[] args)
{
LibraryClient client = new LibraryClient("WSHttpBinding_ILibrary");
PrimaryColor color = client.GetColor();
}
}
}
The app.config files in ClientApp and Library are auto-generated and I have not modified them, and I have not changed the default configuration for the LibraryServiceReference in ClientApp.
When I compile this solution, I get the following errors in the ClientApp project:
Error 1
'PrimaryColor' is an ambiguous reference between 'Common.PrimaryColor' and 'ClientApp.LibraryServiceReference.PrimaryColor'
Error 2
Cannot implicitly convert type 'ClientApp.LibraryServiceReference.PrimaryColor' to 'Common.PrimaryColor'. An explicit conversion exists (are you missing a cast?)
please help me to fix this.
Make sure that 'Reuse types in all referenced assemblies' is selected in the Advanced options of Add service reference or Configure Service Reference.
it's because you're building x64 not "AnyCpu". I am running across this right now, and am trying to figure out if it's a bug, or if it's expected behavior.
Decorate your enum like this:
namespace Common
{
[DataContract]
public enum PrimaryColor
{
[EnumMember]
Red,
[EnumMember]
Green,
[EnumMember]
Blue
};
}
Update Your service reference (with checking reuse types just like Mark stated).
Rebuild your client code.
I have had this issue arise in innocuous, unpredictable manners so many times! I thought I'd share how I "fixed" it this last time.
I am using Visual Studio 2013 - but have had the issue down rev.
The ambiguous reference seems to come on by itself. I did nothing of note to cause it. In the latest instance I was debugging some code behind and suddenly I had 7, then 22 then 49 errors - all of the same nature.
I deleted the service reference altogether and re-added it. Simply modifying the re-use type did nothing. My solution has a WCF service, Class Library, UI and a Control Library. I also removed the using - in some code behind, of the class library.
This is an exceptionally troublesome issue which thankfully only occurs about every few weeks. Why this worked? Beyond my pay grade. I feel your pain! Hope this helps. In this case, the error came on, again, when I opened some code behind on a xaml page.
It sounds like you control both the client and the server code. Why do you want to create a service reference, is there a specific reason or is it just deemed easier?
In projects where you control both sides of the client server application you are better of creating a "contract assembly" (which is probably your common assembly). This contains the interfaces and objects that are involved with the contract and should be referenced by both your client and your server. In order to communicate with the service the client creates a proxy class using the ChannelFactory, there is no need to have a dedicated WCF client.
Example:
ChannelFactory<ISampleService> factory = new ChannelFactory<ISampleService>("Binding_from_config");
ISampleService sampleService = factory.CreateChannel();
sampleService.SomeCall();
factory.Close();
The factory pattern also makes it an ideal candidate for injecting your proxy in via IoC.
The benefits of referencing a common assembly over creating a service reference are:
No ambiguous reference as there will be no need for auto generated classes.
You will not have to update your service reference every time you change the contract.
For what it's worth, I was running in to this same error after moving my data contracts to a separate library. Updated the service references multiple times and tried all combinations of the settings for assembly reuse, to no avail.
What eventually fixed it for me was to 1) restart Visual Studio and 2) update the service reference. The auto-generated code in Reference.cs in the service definition looked very different and did not duplicate my data contract class. It used the proper reference from my library. So something must be getting cached in the IDE.
Hopefully someone else finds this useful.
I was able to fix this by right-clicking on the Service Reference and then changing from "Reuse types in all referenced assemblies" to "Reuse types in specified referenced assemblies" and then checking the specific common assembly.
Just remove the reference to Common project from your ClientApp project and the error should go away. When you're creating a proxy for your service, all dependent code from the service must be injected into the proxy. If you want your types to be same as those on the service side, just enable the 'Reuse types' option while generating the proxy code (otherwise they will be put under a different namespace).
The problem here is that PrimaryColor exists in both Common and ClientApp.LibraryServiceReference and you are referencing both namespaces in your class.
To overcome this issue, either explicitly reference the instance that you require, i.e.
Common.PrimaryColor color = ....
or set up an alias:
using Service = ClientLibraryServiceReference;
...
Service.PrimaryColor color = ......
When making the service reference aren't there some options that say something like: "inlcude common types in generated service contract" ?
I have the idea that in your service reference the classes are "copied" and that's why you get this error. Inspect the generated service files, remove then and add them again with "Add Service Reference" and see what options you have there.
EDIT
Although I'm almost sure that the Type PrimaryColor is defined twice. One time in the common project and one time in your service reference, you can also try this in your clientApp (to more explicitely specify the PrimaryColor Type):
Common.PrimaryColor color = client.GetColor();

Type being passed through web service not being recognized by consuming code

I am creating an XML web service that passes an array of custom types. In my consuming code I am referencing the code as a web reference which I have given the namespace MYWS. Now in code I am trying to assign the results of my web service call to an array of my type like so :
'instance to make a call to my web service
Dim srv As New MYDWS.ServiceNameWSSoapClient
'array to hold the results
Dim arr() As MyClass
'assign the web service call results
arr = srv.myWebMethod()
When I do this the complier complains, saying:
Value of 1 dimensional array of my.namespace.MyClass cannot be
converted to 1 dimensional array of my.namespace.MYWS.MyClass because
my.namespace.MYSW.MyClass is not derived from my.namespace.MyClass
Now I understand the message, the thing is they are the same class. The class is declared in my calling code by the web service references a dll from that project. How do I tell the compiler that these are the same type? Any help would be very much appreciated. Thanks!
The upshot is that you have a namespace mismatch. If you right-click on MyClass in your example and select Go To Definition, where does it take you? I suspect that you may end up in a locally defined class.
The solution is to change
Dim arr() As MyClass
to
Dim arr() As MYWS.MyClass
Update based on information in comments
The problem with using the web service is that you cannot cast it to a local class.
You have a couple of options depending on exactly what you need out of the local class.
If you only need methods to act on the data in the class or you need additional properties, you can create a partial class in your environment that extends the class created by the web service. For example:
Namespace MYWS
Public Partial Class MyClass
Public Property SomeAdditionalData As String
Public Sub SomeMethod
' Perform some operations on the class members
End Sub
End Class
End Namespace
However, if you have calculations or other work embedded in the class, then you will need to get the data using the web service class, then copy the data from that class into your local class. If the properties have the same names, you could ease this task using reflection.
As another option, if you have control over the web service, you could change it to a WCF service. This will allow you to reuse the exact same class code on both ends of the communication pipe.
Found a solution to the problem. In the web.config I found this:
<add key="net.mydom.mydom" value="http://localhost:7452/dir/mysvc.asmx"/>
which was what the system automatically entered when I registered the web service. I got the error messages on screen, but everything compiled and ran w/o problem.
When I manually changed to this:
<add key="net.mydom" value="http://localhost:7452/dir/mysvc.asmx"/>
The error messages went away and everything continued to function as expected.
(That only took my 7 years to figure out...)
UPDATE:
Well, not quite the fix, but it must be close. After awhile, the problem came back, when I switched back to to:
<add key="net.mydom.mydom" value="http://localhost:7452/dir/mysvc.asmx"/>
it went away again...sure to come back at any time...
UPDATE
If I explicitly add:
imports net.mydom
to the top of my code, the message goes away again (even though I was explicitly using the full net.mydom. when typing the variables.

WCF 'sub main' not found

I must be losing my mind...
After getting a test WCF hosted in a windows service, I'm trying for another one (practice, practice, practice).
I created a WCF service library, added one function. Then created a Windows Service, and added my WCF to the project. Did the rest of the stuff located here (http://joefreeman.co.uk/blog/2010/03/creating-a-setup-project-for-a-windows-wcf-service-with-visual-studio/)
Now I'm getting this "Sub Mian was not found in [WCF app]" error when I try to build the solution.
I didn't think WCF projects required a Sub Main as they are services and not applications. What am I doing wrong? I didn't have a sub main in my last project. Any ideas?
For others who are looking for the same answer I was...
Created a service in VB.NET (VS2010), and was getting the same error listed above...
'Sub Main' was not found in 'SERVICENAME.Service1'.
In VB.NET, VS2010 created a "Service1.Designer.vb" file for me automatically. Inside of that file was:
Shared Sub Main()
Dim ServicesToRun() As System.ServiceProcess.ServiceBase
' More than one NT Service may run within the same process. To add
' another service to this process, change the following line to
' create a second service object. For example,
'
' ServicesToRun = New System.ServiceProcess.ServiceBase () {New Service1, New MySecondUserService}
'
ServicesToRun = New System.ServiceProcess.ServiceBase() {New SERVICENAME}
System.ServiceProcess.ServiceBase.Run(ServicesToRun)
End Sub
To resolve this, right-click your solution name in the solution explorer, go to the "Application" tab, and pick "Sub Main" as your Startup object in the "Startup object" drop-down box. Recompile.
Granted, the file names and structure will be different in C#, but the idea is that Visual Studio put the Main procedure SOMEWHERE, and it hopefully should already know where it is.
The WCF service itself doesn't need a Sub Main, but your Windows Service does.
Compare against your previously built, working Windows Service.
edit: using C#, when I create a new project using the Windows Service template, I get the following initial code in a Program.cs file (static void Main is your Sub Main). I'd be very surprised if you don't also have this in your Windows Service.
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
static void Main()
Check you haven't accidentally changed the Application type to something stupid like "windows forms app", hit the properties of the project and make sure it's on "class library".

Reference Windows Form Project From another Windows Form Project in same Solution

I have a solution with several projects most of which are code or control libraries. I have a main windows forms application that references and uses these libraries. What i am trying to do is create a 2nd windows application that extends the main one, but i would like to be able to deploy them as separate exe's.
When i try to add a reference to the new app referencing the main app; all seems fine until i try to run the new app i get several error msgs similar to below:
Error 1 Could not find file 'ADODB.dll' referenced by assembly 'D:\Visual Studio 2005\Projects\X\XX\bin\Debug\XXX.exe.manifest'. <newAppName>
i have tried adding references to all the dll's in the error messages and they are still listed when i try to run the new app. I thought of a few work arounds but they require user changes to maintain separate exe's at deployment. I would like to avoid this if possible. Any ideas?
Thanks in advance, Jeff
Your windows forms applications should not be the point that you extend, the exe files should really just be a shell for launching your process (as much as possible anyways). So this response doesn't answer your specific problem of reference exes as this is not considered good practice.
All the extensions should be made to your code or control libraries off a known interface or contract. Generally the process for extending applications like this is to use alternate or additional DLLs which are loaded at runtime.
Say you have an application called clock which is to display the time.
You can structure your application with a set of contracts (or interfaces) in a referenceable DLL "Clock.Contracts.dll":
public interface ITimeService
{
public string Name { get; }
public Date GetTime();
}
You then have each implementation of this in another DLL ("Clock.LocalComputer.dll", "Clock.InternetTime.dll"
public class LocalTime : ITimeService
{
public string Name
{ get { return "Local Time"; }}
public Date GetTime()
{ return Date.Now; }
}
In the UI/EXE you always reference the interface don't call the implementation.
How do you get an instance of the implementing class, using Reflection to identify if a class in a DLL implements the interface and Activator.CreateInstance to generate the class.
http://gsraj.tripod.com/dotnet/reflection.html
There are patterns like Inversion of Control and Dependency Injection which help to address these things in a standardized way in your application. 3rd party libraries like Castle Windsor, Spring can assist. A google search on these will give you some reading material.
I will say that it can take a while to fully get your head around these things.
ok i found a reasonable work around. Basically you add all the reused forms as existing items, but instead of just clicking add you click the drop down arrow and choose add as link.
It would be great to redesign as JTew suggested above but this gets me where i need to be without having to move code.
You can find more information here
Thanks for all your time looking this over and hopefully is helpful to more
Jeff Spo