I think that we can all agree that any tool or design pattern we use, after a degree of hard labor and sweat, ought to produce some tangible benefit. I am sorry but I am failing to see that with Csla 3.8.3
After creating a reasonable looking SL project that works like a charm on my development machine, 4 days ago I decided to install it on my web server - those have been four days in hell. I have sought help by posting here but nobody is interested in answering my questions.
I get no errors of any kind, the only thing I know is that none of my DataPortal_xyz methods are even touched in the server code.
I have unzipped the file in the ClientBin and looked at the ServiceReferences.ClientConfig file again and again and it points to the correct website.
I thought may be the amount of data being brought was too much. So I started hacking off one object after another from the graph with no benefit. Finally, my Root object is required to do only one thing - return a string that says "This is all I got" , and on my local machine it does so. But on the server - nothing.
There are no error and no warnings in my solution.
The only thing that may be causing a problem - and I do not know where to go with that - is that about 2 weeks ago I set up compressions per instructions posted by James Thomas. After working with that for a few days, I realized that using the prescribed method I could not take care of three business libraries that I have in my solution, so I backtracked the instructions by removing/undoing everything. I don't know if that has somehow left behind a residue.which is now causing a problem.
About 2 months ago I installed the project on a windows 2003 server, and worked fine - we were showing the design to the customer. This time, I have tried doing exactly what I did before on windows 2003 and also in a new website on windows 2008. Nothing but Failure.
Jav
Hi, Jav.
I had a similar problem a while back - couldn't figure out why DataPortal calls weren't getting to the server side. The solution to that particular episode was that I needed to comment out the line:
Csla.DataPortal.ProxyTypeName = "Local"
in the Application_Startup method of the SL application. Problem solved!
You may want to look at something along those lines as to what's causing your issue ... ?
Hi Greg,
Thanks for your help. I do not have that line Csla.DataPortal.ProxyTypeName = "Local" anywhere in my SL App.
Jav
You're obviously very frustrated....
My experience with setting up SL on a Windows Server 2003 machine was that it was pretty painless. I would say, setting up other things on Windows Server 2008 boxes have been more difficult. There are odd new IIS limit settings and various security issues that seem more involved. I haven't set up a Silverlight app on a 2008 box yet. Maybe someone else can attest to any special considerations that need to be taken.
I don't quite understand the despair over what's probably a configuration issue. I feel your pain, I've had frustrating glitches that shouldn't take that long weigh me down too.
But what are you looking for w/ your post? I have to confess I don't remember seeing specific posts from you about it (I'm sure you made them). Maybe you should include a link to your post(s) in this thread.
Hi skagen,
When it comes to computers and software, I have the patience of Gandhi - it is the business deadlines that get me frazzeled.
We were supposed to have a teleconference with the client tomorrow to show our progress and get some feedback and I was dying to show them the great stuff. Luckily, we have had a relationship with this client that goes back a couple of decades. The folks over there were able to calm me down, and now I'm breathing normally again.
I love Csla, can't see myself writing code without it - except when I'm writing iPhone Apps (Objective C has its own MVC system)
I bought Rocky's first Business Objects book that came out even before the .Net., and have been his disciple ever since.
Since you asked, here is the the link to my original post
http://forums.lhotka.net/forums/t/9051.aspx
Jav
Hi Jav
I can sympathise with you - it's not fun trying to figure this stuff out sometimes, but really I don't think you can blame CSLA and call it a total failure - there are plenty of us gaining a lot of value from it.
I'm not sure I can help you directly - I'm not running the latest version - but I do my configuration dynamically. I'll post the details of this below in case it helps. One piece of advice I'd give is that I've usually found that problems become much clearer after you fully understand them. Have you tried using Fiddler to see what's going on?
Anyway, here's the details of my code:
My ServiceReferences.ClientConfig looks like this:
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IWcfPortal" receiveTimeout="10.00:00:00"
sendTimeout="10.00:00:00" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" />
</basicHttpBinding>
</bindings>
</system.serviceModel>
</configuration>
In my App.xaml.cs, at startup I do the following:
private void Application_Startup(object sender, StartupEventArgs e)
{
bool enableFiddler;
bool useCompression;
ExtractStartupParameters(e.InitParams, out enableFiddler, out useCompression);
ApplicationUri = GetApplicationUri();
ConfigureWcfProxy(enableFiddler, useCompression);
...
}
The ExtractStartupParameters pulls various parameters out of the StartupEventArgs.InitParams (which I set up on the ASPX page on the server)
GetApplicationUri is as follows:
private static string GetApplicationUri()
{
// Dynamically construct the URL
var pageUri = HtmlPage.Document.DocumentUri.ToString();
return pageUri;
}
Then my ConfigureWcfProxy code is as follows:
private void ConfigureWcfProxy(bool enableFiddler, bool useCompression)
{
var baseUrl = ApplicationUri.Substring(0, ApplicationUri.LastIndexOf("/"));
if (baseUrl.Contains("localhost") && enableFiddler)
{
baseUrl = baseUrl.Replace("localhost", "127.0.0.1.");
}
var svcName = useCompression ? "CompressedWcfPortal.svc" : "WcfPortal.svc";
if (useCompression)
DataPortal.ProxyTypeName = typeof(Library.Compression.CompressedProxy<>).AssemblyQualifiedName;
if (ApplicationUri.ToLower().Contains("https:"))
{
var binding = new BasicHttpBinding(BasicHttpSecurityMode.Transport);
binding.MaxBufferSize = int.MaxValue;
binding.MaxReceivedMessageSize = int.MaxValue;
binding.ReceiveTimeout = TimeSpan.FromMinutes(10);
binding.SendTimeout = TimeSpan.FromMinutes(10);
binding.OpenTimeout = TimeSpan.FromMinutes(10);
WcfProxy.DefaultBinding = binding;
}
WcfProxy.DefaultUrl = baseUrl + "/" + svcName;
}
Obviously, Library.Compression.CompressedProxy is where I've put the code for the compressed proxy.
Hopefully some of the above code will help you. For me, it works fine whether in development or deployed - I don't need to change anything.
Cheers...
Craig
Hi Craig,
Thank you for all your suggestions. It is going to take some time for me absorb all of it. I have printed out your post and would go over it carefully.
One question about ServiceReferences.ClientConfig. All the samples and the code from Rocky's demos have an EndPoint which I don't see in your the code in your post. Is that not needed? Mine looks like the following:
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IWcfPortal" maxBufferSize="40000000"
maxReceivedMessageSize="40000000" receiveTimeout="00:10:00"
sendTimeout="00:10:00" openTimeout="00:10:00" closeTimeout="00:10:00">
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost/WcfPortal.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IWcfPortal"
contract="Csla.WcfPortal.IWcfPortal" name="BasicHttpBinding_IWcfPortal" />
</client>
</system.serviceModel>
</configuration>
It is the endpoint address that I was referring to in my post.
Jav
Hi Jav
No, I don't have the endpoint configuration in my config. It's been running in development and production (dozens of sites) without it for some time - I believe it's because of my dynamic configuration, though can't say for absolutely sure! 
When I get a moment, I might do some experimentation to find out why.
Good luck!
Craig
Aah! Dynamic cofiguration. While searching for answers to my problems yesterday I did come across a post where someone wanted to know how to do a dynamic configuration. Was that you?
I am wondering if my attempt at "implementation" of MVVM has something to with my problem. Last time I installed the project on the server I was using the CslaDataProvider. Now all my interaction with the buiness layer is through the ViewModel. Oh, I hope that's not it. I was just beginning to get the hang of it.
Javed
Your problem sounds very much like a WCF config issue. Fiddler is a good first step - find out if traffic is even on the wire at all.
Rocky,
Since I am using ViewModels instead of CslaDataProviders, my problems may be caused by that. Since I had plugged them in after my project was fairly well advanced, I thought that I should try using them on something very basic first.
So this morning I started on a tiny test project with a ViewModel, and after 3 hours I am still trying to make it work even on my local machine. (Strange that my other project appeared to be going along fine!) As a beginner with ViewModels, I am finding your MVVM sample somewhat bewildering.
I am going to post that project in a few minutes under a different topic. Perhaps it can be educational for others like me.
Larry,
Thank you for your comment. Yes, I know about the ServiceReferences.ClientConfig file's EndPoint and I have even been checking it the .zap file to make sure it is pointing to me website correctly.
Jav
I can identify with that. Indeed the failure is mine, not of the DataPortal. You and I have been using this old friend for years now.
I do appreciate your suggestions, but more than that your experience of painstaking work to get everything working. I am on it now. I have never used Fiddler. Is that something that you install on the server? (geez, I should be embarrassed to ask that question, wouldn't you say?)
Thanks Dan.
Jav
Hi Jav Definitely use Fiddler - it's essentially a proxy that is installed on the client so you can see exactly what traffic is going to your server. And helpfully you can see the errors caused by WCF misconfiguration rather than the not-very-helpful "not found" you usually get.
You can find it via Google, or http://www.fiddler2.com/fiddler2/
It really will help!
Good luck...
Craig
Okay -the Fiddler was exactly what I needed. After a few tries, and after fixing some easily fixed errors, I know appear to up against some security settings in the server. The fiddler stops with 2 lines:
403 HTTP ........ /clientaccesspolicy.xml
403 HTTP ........../crossdomain.xml
and then I get a big old window with one good news that my URI was right on target, followed by the bad news that reads like this:
This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details. ---> System.Security.SecurityException ---> System.Security.SecurityException: Security error.
at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.Browser.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)
at System.Net.Browser.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)
--- End of inner exception stack trace ---
So it's that old security trap of some sort again. Says "contact the owner of the service". That's funny, 'cause that's me!
So - what do I do now? Look up in my 2300 page book or what! Thanks for the help. I think I'm gett'n there. Just a litlle nudge is all that I need.
Jav
Hmmm... do you have crossdomain.xml and clientaccesspolicy.xml files? You need them and they need to be accessable from your site.
So, in your web browser, what happens when you go to http://{yoursite}/crossdomain.xml ?
Same for clientaccesspolicy.xml
A 403 is a security-related response I think...
Both of those come back with:
404 File or Directory Not Found
All the websites on the server use https:// to gain access. That is how this test site was also configured. But the first message I got was that I was using https:// where http:// was expected. So just for fun I changed the SSL on this particular site off (and also changed my ServiceReferences.ClientConfig) to http:// from https://, and that resulted in this message coming up. (Obviously I cannot explain why I was getting this error message, either)
Also, before I hit the SL App, I have to login, after which I have to select a person from a database to work with before the control jumps to the Silverlight page. All of those steps go just as expected (with or without SSL). The Silverlight controls also get created and everything looks just fine. All that is missing is the information from a database to which all the SL controls DataBind (this database is different from the database from where the Person list was loaded). In fact I can close the error dialog and click the back arrow and I am back at the Person List (Of course the Silverlight App is terminated).
The Permissions on all three databases (Login, person list, and SL DataBind) are exactly the same and are not the issue.
Jav
I'd say completely ignore your databases for now. It's not getting anywhere near them.
Can you post the exact address you're seeing the 404 on? Are you absolutely sure this it the base address that the data portal is going to?
Another thing you can try to test whether your WCF service is working is to put its address in the broser - e.g. http://localhost/{yoursite}/WcfPortal.svc Does that come back with a nice page showing the details of the service?
It looks like that my Server2008 iis7 does not have the correct MIME to display that page. I get error 404.3. About 6-8 weeks ago I had intalled the same App on a server2003, and it worked just fine. When I typed the same url for WcfPortal.svc in the browser, the 2003 box gave me the proper response telling me all about web services etc. In other words, it worked. I tried to see what MIME types were listed in the iis, but could not find a list - I did find a place where I can add a new mime - but no list.
Back in the 2008 box, the iis gives you a mile long list, but svc is not listed. I saw wsdl listed as text/xml. I searched, briefly, the internet for 404.3 (In fact I came across this error just 2 days ago at the Microsoft website somewhere but I'll have to search for it) Most of the responses to questions suggested messing with the MIME types.
I tried entering .svc as text/xml, but all it did was to bring me a blank page. So I promptly removed it from the list. With WCF oozing out of Microsoft for years now, is it not amazing. But then again my sense is that the problem may not be related to the absence of .svc in the MIME types. If that was the case we will hear a whole lot about it, probably Rocky would mention it in his book, blog or Video.
Jav
Oh, I forgot. Over the internet the response from the server was a rather rude one liner quoting error 404. I went to the box and typed the Internet (not localhost) address, I got the error with the following message:
HTTP Error 404.3 - Not Found
The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map.
I have the a fat iis book lying here for a few months. May be it is time I made use of it and looked up this configuration thing. If you ask me this configuration stuff is turning into a conflagration. Just kidding. Couldn't resist. Sorry.
Jav
Hi Jav
I'm not clear whether you've got the .svc working yet or not...
But you don't need to set it up by hand - there's a tool for that called ServiceModelReg - which sets up the server for WAS and IIS hosting for WCF (something like that anyway ). It's documented here: http://msdn.microsoft.com/en-us/library/ms732012.aspx
Craig
Hi Craig,
I have also been researching the issue. I came across this article on msdn which sounds interesting. It's getting late right now. I'll read it tomorrow.
http://msdn.microsoft.com/en-us/library/cc197955(v=VS.95).aspx
Its title is "Making a Service Available Across Domain Boundaries" and one of the headings is "To use a clientaccesspolicy.xml file to allow cross-domain access" - exactly the terms we saw in that Fiddler output. When I saw that, my first response was - get outa heer - really!!! We'll see if it lives up to its promise.
The other thing I have noticed is the security for Internet zone on the server is tighter than a drum - well it is at the absolute maximun - can't go any higher. I wonder if that has anything to do with the issue.
Jav
Yes, those files are absolutely essential otherwise Silverlight wil refuse to communicate with your service. That could well be your major problem if you don't have those.
All you have to do is have those files served up by your web server in the root of your app - i.e. the same folder as the WcfPortal.svc file. Just add them in as content files to your web project that's hosting the service (assuming you're doing it that way).
The contents of my files are:
crossdomain.xml:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
clientaccesspolity.xml:
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="http://*"/>
<domain uri="https://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Cheers...
Craig
Hi Craig,
I have certainly made some progress. Now that I crossdomain and clientaccesspolicy files are there, fiddler is no longer putting up those red lines. Also the Silverlight page load is much smoother, except no data to bind to.
When I sit down at the server box and type the internet address of the site and ask for WcfPortal.svc, I get Error 404, sometimes error 404.03 with the explnation that file is not found. Then just for grins, as Rocky would say, I copied WcfSlPortal from one of his demos to a Flashdrive and placed it into the site. Of course I knew what it will say. I got the same answer - File Not Found.
Very annoying. It's like asking your kids; Johny where's Carla's teddy bear? "I don't have it".
I suspect it is one of those MIME thingies. It knows the file is there but the site doesn't know if it should serve it. Hence the simple answer, I don't have it. Yesterday I tried entering it but it asks what type it is - I typed text/xml but that is probably not right. May be some will chime in. I know I'm this close. Thanks for all your help man. cheers.
Jav
It is possible that the .svc extension isn't routing into ASP.NET on your server. You should check that - and/or use the asp_regiis tool to re-install ASP.NET on the server perhaps.
Hi Rocky,
You must be at the Tech Ed, it's been so quiet here lately.
How would I check to see if .svc is routing into ASP.NET?
Jav
Yes, I'm at Tech Ed this week - on vacation next week so it will be even more quiet from my end.
The dialogs for linking extensions to handlers is different depending on your version of IIS - but it is always lurking there somewhere - in the MIME type dialog for the server and/or web site.
This is a Server 2008 Web Edition. In the Server Manager, under .Net Framework 3.0, there is something called Wcf Activation which was not turned on. I turned it on and re-booted the server. This has not made a difference.
Jav
Hi Jav
Don't try to register the .svc extension by hand - you'll probably get it wrong.
As Rocky pointed out, it's worth running aspnet_regiis to check that the ASP.NET configuration is correct for the server. The run ServiceModelReg.exe and that will configure the server for WCF - and it will then be able to serve .svc files.
This really should be fairly simple once all the pieces are in place.
Craig
Windows Server 2008 does not appear to have aspnet_regiis. It does have something called AppCmd.exe and I'll have ro read up on how to use it. I also do not find a ServiceModelReg as I serch it in the Server. I'll see what Appcmd has to offer. Thanks.
Jav
The regiis application is part of the .NET SDK - it would be in c:\windows\microsoft.net\frameworks
I used regiis -i to reinstall Asp.Net, but it has not made a difference. My iis 7 book talks about additional bindings if we are going to be using net.tcp. I didn't think we are using non-HTTP so that is the only thing (adding bindings for net.tcp) that I have not done.
I am going to get back in the Vidual Studio and go over all of the config stuff, make sure everything is okay there, then clean up and Rebuild. I did the last built early this morning and at the time I had a lot else on my mind.
Jav
Well, at least now I have different error message when I try to open WcfPortal.svc file. Previously it was simple File Not Found. Now the message is:
Could not find a base address that matches scheme http for the endpoint with binding BasicHttpBinding. Registered base address schemes are [https,net.tcp].
The website uses SSL. Does that mean I should create bindings for https in the config file. I already tried using the AppCmd.exe to register http and https, The error message has not changed.
Here is what I have in web.config:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<services>
<service behaviorConfiguration="returnFaults" name="Csla.Server.Hosts.WcfPortal">
<endpoint binding="wsHttpBinding" contract="Csla.Server.Hosts.IWcfPortal" />
</service>
<service behaviorConfiguration="WcfPortalBehavior" name="Csla.Server.Hosts.Silverlight.WcfPortal">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IWcfPortal"
contract="Csla.Server.Hosts.Silverlight.IWcfPortal">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="returnFaults">
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
<behavior name="WcfPortalBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IWcfPortal" closeTimeout="00:10:00"
openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"
maxBufferPoolSize="400000000" maxReceivedMessageSize="400000000">
<readerQuotas maxStringContentLength="400000000" maxArrayLength="400000000"
maxBytesPerRead="400000000" />
</binding>
</basicHttpBinding>
</bindings>
</system.serviceModel>
By turning off the SSL on the website and using http://, I can connect to the WcfPortal.svc and it gives me a civilized message about how I can use svcutil.exe to create this and that and then use the service. Of course, I probably don't need to go there.
However, after connecting to the website and displaying the silverlight page (which looks just fine as far as the controls are concerned), nothing appears to be brought from the DB for DataBinding. In other words, I am almost there.
In Fiddler output, I see listing for the Login page, then Default.aspx, then Silverlight.js and the last line has the ClientBin. After that all is quiet. I am wondering: Would it help if I install VS on the server and then walk thru the code while connecting using the Internet uri instead of localhost. I have never tried that, so my question is would I be able to create breakpoints. I don't see why not!
Jav
Sounds like you're making progress. At this point I'd be using Fiddler to see all the traffic coming from the SL client to your server - you should be able to tell from what what requests are made and what results are being returned.
I would certainly try all this out on HTTP first before complicating things with SSL.
Craig
Unfortunately Fiddler becomes totally silent once I hit the Silverlight page. The last line in Fiddler is when the excution hits the ClientBin. After that I hear nothing from Fiddler.
Jav
I'm a bit confused by this - you said you were seeting traffic in Fiddler that was giving you the error about the clientaccesspolicy.xml and crossdomain.xml files. So therefor the SL app was trying to access a service. Now that you've fixed those, you're no longer seeing that traffic?
The only tip I can give there is to put up a message box in your SL app showing what the address the data portal is trying to talk to - that would be:
WcfProxy.
DefaultUrl
Then ensure that that's correct. There was a version of Fiddler that wouldn't log traffic going to localhost - you had to use the IP address (127.0.0.1) and put a dot on the end - i.e. 127.0.0.1. to make Fiddler work. But I don't think that's your case.
At this stage, I'd say remove all the complications you can - build a very simple ASPX page hosting a new SL app that just makes a call to your service - i.e. loads a business object or list. That should be relatively simple to do, and would isolate you from any other complications that are potentially causing the issue.
Craig
I agree that I should start with a very small project and get the plumbing working correctly first. I did install one of Rocky's demos from video series on the server and it worked fine also. So I think that the server's WCF configuration is now okay. Difficulty with this kind of a mess that goes on for days is that in trying to do this and do that one ends up with a mess in the project itself with a patch here and a patch there. Pretty soon, the patches become a bigger problem that bugs.
In the early stages I did install the project on a server 2003 box, and it worked like a charm. Assuming that it was going to be 'no sweat', I didn't bother installing again until now when I have all sorts of things going.
Start with a small project, and plug it on the server regularly, is what I'll do. Thanks for your help Craig.
Jav
You're welcome.
Deployment is usually a bigger problem than it seems.
So you have it working now?
Craig
SUCCESS. Hurray. It's Alive, its alive!
YES!
DataPortal ROCKS!
Jav
Jav,
Maybe it's time to update the title of your post (if at all possible) to "SL - DataPortal a Total Success"?
Have you isolated the cause of the issue, and can you post that for the benefit of others in the future?
Regards,
Stuart
Stuart,
I would love to be able to change the title, but I think only Rocky can do that. I would actually appreciate if he would do just that. This is the third major application I am developing with Csla. I would probably still be struggling with the first if it hadn't been for Csla.
I would be happy to share some of the things that I have learnt.
1. Make sure your server is properly configured. In Server 2008, you have to take care of two things: a. Make sure ASP.Net is installed properly b. Out of the box, Server 2008 is not ready for WCF, you have to install it. Use the Server Manager, Click Add Feature and install WCF HTTP ( you can also install Non-HTTP) Activation Feature. If you are using non-HTTP protocols, you will need to perform the additional step of updating the website's bindings by using AppCmd.exe
2. Prepare your App's configuration carefully. 80% of my headaches were caused by me trying to add a Service References. My troubles went away when I copied a ServiceReferences.ClientConfig file from one the SL Video demos (I used Demo 6), and pasted it into my SL project and all ...Client projects. Then I simply modified the web address in each as needed. Even with that I kept getting occassional compile errors until I deleted every one of those ServiceReferences from my projects, and swore never to touch ServiceReferences again. I also found out, the hard way, that every time you go and create a "ServiceReference", your web.config gets some lines added to it - which by itself can mess things up. For Web.config - just copy and paste the lines from one of the demos and modify them to suit your purpose.
3. Two absolutely necessary files. They must reside in the root of your website where the WcfPortal.svc file is For more on that use this link that I posted earlier also:
http://msdn.microsoft.com/en-us/library/cc197955(v=VS.95).aspx
Craig posted the contents of these two files above. In the clientaccesspolicy.xml file, to begin with it is probably better to allow both HTTP and HTTPS. I have just been using an asterisk and that has worked fine. (If when you test your WebService (see below), and you keep getting an error about https// or http//, you can bet that the problem is with your clientaccesspolicy.xml.
4. Compiling your App for installation on the server: Make sure all of your ServiceRefeferences.ClientConfig files are pointing to your website address, and pay particular attention to to http:// setting - it is hard to tell it from https:// All of these files should be consistent. I never figured out which of these get inserted in the ClientBin zap file, I thought it should be the one in the SL project but I was not sure examining the zap file.
5. I don't even know why we still have Publish command - it requires FrontPage Extensions which are now obsolete. I just use a Web Deployment Project and simply copy and past into the website, it is just a matter of going from my right elbow to left elbow. Well - not quite - I do have to take a few steps.
6. Before going anywhere else, test your WCF first by using http://www.yourwebsiteaddress/WcfPortal.svc What you want to see is a civil, downright polite and respectful message. Anything other than that means you won't go anywhere - you got some fixin to do.
7. Use Fiddler - it will be a music to your ears. If everything is working smoothly, you should see one or more entries in the Fiddler output showing WcfPortal in the line. When there is database access you should see the number of bytes - initially -1 and then jumping to the actual value as the asynch operation is doing it magic.
Well that's all I got. Have fun
Jav
Jav,
In your ServiceReferences.ClientConfig file you do need the endpoint address unless you are using some dynamic config method. In your post you show localhost in the endpoint address and that is fine for the development machine but make sure it is the correct address for the target production system. You could try substituting the actual IP address instead of "localhost" for the endpoint config.
Larry
Copyright (c) Marimer LLC