I am having difficulty deploying RIA services/Silverlight 3 to a staging environment.
Here is my situation:
1) I am using RIA for authentication. This works fine on both my development machine and in the staging environment.
2) I created a custom LinqToEntities RIA service to get data from the database into my application. This service works fine when I do a local build, but does not work on the staging server.
The server side RIA code never gets called when the client makes a call to it.
The RiaContext appears to be initialized ok, i.e. it does not throw an exception.
I use code sililar to Context.Load(qry); to put data into the entities. The LoadOperation's complete event fires, but no data was loaded, the serverside methods were never called.
Any ideas on what may be wrong?
I would check to make sure that you have:
The correct connection string in your web.config.
The application is configured to run under a service account that has permissions to access the database.
Your Context.Load should be passing a completed event handler and in that handler you chould check that the LoadOperation.HasError is false. There will be no exception thrown if something went wrong, you have to explicity check for the error.
Related
I added a DataContract to my service and tried updating the service reference to get access to that DataContract. But it never showed up in the intellisense. I cleaned and built the project and then updated the service reference, but it still didn't work.
I then published it to the server and updated the service reference so it would point to the server, but I get the same thing. I browsed the service through IIS and opened my service in the browser.
I clicked the top link that had Service.svc?wsdl to see if my DataContract was there. An old MessageContract was there, but the DataContract was not.
Any ideas on what I'm doing wrong here?
Delete the currently deployed service binaries and verify that the service is inaccessible. Then deploy the new service binaries. This is to verify you're actually deploying to the correct location.
It is also possible that the service binaries aren't being rebuilt. To verify this, delete your bin folder (located next to your project file generally) and issue a rebuild, then follow the first steps.
I got my answer from here.
Only the types actually used by the service will be reflected in the metadata.
I didn't have an operation contract that used the DataContract. I didn't need to have one at the time, so I didn't make it. But apparently, unless you have one that uses it, the metadata won't be generated for that DataContract.
I am using EJB3 deployed on WAS 8.
I am accessing this EJB from my WEB server using Context.lookup.
This look up works fine and the entire application works fine for the first time after WAS is restarted.
However when I run the application for the second time, the look up does happen, but a NULL value is returned.
I dont get any exception or error or any logs on WAS.
Again if I restart the WAS, the application works well.
Can anyone please guide what the issue can be?
Remote references are connection-less proxies. If the application is redeployed/undeployed or there is network failure, the proxies are invalidated.
You can use ServiceLocator pattern for caching the references of the remote objects. You can remove & again re-create them with JNDI lookup when they become invalid.
I have a SL navigation application, that currently runs on a shared hosting package with a 3rd party ISP. I can login, and register using the ASP.NET membership and role providers.
I have now setup a dedicated server, on which only my app will run. It does not yet have a domain name that points to it... I access it via an IP address.
I've copied the entire site (including the ClientBin and all the XAP's) to the new server, but the Authentication and Registration services don't work... they just return NotFound.
When I check Fiddler on the working site, this service is called :
www.myaddress.com/ClientBin/MyApp-Web-AuthenticationService.svc/binary/Login
which of course succeeds. However, on the other site, the fiddler trace looks the same (because I just copied the site) :
123.123.123.123/ClientBin/MyApp-Web-AuthenticationService.svc/binary/Login
but, the call fails with NotFound. Fiddler reports it as HTTP/1.1 500 Internal Server Error. When I open
http://localhost/ClientBin/MyApp-Web-AuthenticationService.svc/binary/Login
on the server, I get the HTTP/1.1 500, as well as this description :
Handler "svc-Integrated" has a bad module "ManagedPipelineHandler" in its module list
Which leads me to believe that there is something wrong with my IIS config, as the exact same code is working on another system.
What is a "bad module"? How do I fix it?
Normally this type of error is that ASP.Net is not activated or that a handler for svc is not registered or registered correctly.
In your case is looks a bit different. It could be that you have .net framework 4.0 code that you are trying to run in a .net framework 2.0 application pool.
IIS 500 errors often show up with more information in the Windows Event log - if you can somehow get access to that?
Also I've noticed that often the server will actually send debugging output back to the client that everything seems to ignore. Have you checked the entire raw response that is coming back from the server to see if there are any clues there?
I have a Silverlight 4 client running on a Facebook page hosted on Google App Engine. It's using gminifb to communicate with the Facebook API. The Silverlight client uses POST calls to the URIs for each method and passes the session information from Facebook with each call.
The project's growing and it would be super-useful if I could set up a unit-testing system to make a variety of the server calls so that when I make changes I can ensure everything else still works. I've worked with nUnit before and I like what I've read of PEX but I'm not sure how to apply them to this situation.
What're the choices for creating a test system for this? Pros/cons of each?
How do I get started setting something like this up?
Solved. I did it as follows:
Created a special user account to be used for testing on the server that bypassed the authentication. Only did this on the test environment by checking a debug flag in that environment's settings. This avoided creating any security hole in the live site (since the same debug flag will be false there.)
Created a C#.NET solution to test each API call. The host project is a console app (no need for a GUI) with three reusable synchronous methods:
SendFormRequest(WebRequest request, Dictionary<string,string> pairs),
GetJsonFromResponse(HttpWebResponse response),
and ResetAccount().
These three methods allow the host project to make HTTP requests on the server and to read the JSON responses.
Wrapped each server API call inside a method call in the host project.
Created an nUnit test project in the solution. Then simply created tests that call each wrapper method in the host project, using different parameters and changing values on the server.
Created a series of tests to verify correct error handling for invalid parameters and data.
It's working perfectly and has already identified a few minor issues that have been found. The result is immensely useful and will check for breaking changes on new deployments.
In ASP.NET, I usually log exceptions at server-side, In windows forms I can either log exceptions server-side or write to a log file on the client. Silverlight seems to fit somewhere in between.
I wanted to know what everyone else is doing to handle their Silverlight exceptions and I was curious if any best practices have emerged for this yet.
For real logging that you could store & track, you will need to do it on the server, since you can't be guaranteed anything on the client will be persisted.
I would suggest exposing a "LogEvent(..)" method on a server side web service (maybe you already have one) which would then do the same kind of logging you do in ASP.net
Here's a video about basic web service calls in Silverlight if you haven't done that yet
http://silverlight.net/learn/learnvideo.aspx?video=66723
I'm not sure about any logging best practices though, my first guess would be to do the best practicies for logging in a web sevice on the server and expose that to the client.
Hope this helps!
I would say that Silverlight fits much better to ASP.NET side of the model. You have server which serves web page. An object (Silverlight app) on the page pings data service to fetch data and display it.
All data access happens on the server side and it does not matter if data is used to create ASP.NET pages on the server or sent raw to the RIA for display. I do log any failures in data service on server side (event log works fine) and do not allow any exception to pass to WCF. When client does not receive expected data (it gets null collection or something similar), it display generic data access error to the user. We may need to extend that soon to pass a bit more information (distinguishing between access denied/missing database/infrastructure failure/internal error/etc), but we do not plan to pass exception error messages to the client.
As for client side, sometimes we may get in situation where async call times out -- it is just another message. For general exceptions from client code (typically, bugs in our code), I just pass exception to the browser to display in same manner as any script exception.
Also take a look at the new Silverlight Integration Pack for Enterprise Library from Microsoft patterns & practices. It provides support for logging exceptions to isolated storage or remote services and is configurable via policies in external config or programmatically. Batch logging and automatic retry (in case of occasionally connected scenarios) are also supported.
Use the Isolated Storage available for Silverlight application. You should store here your log.
Then you can develop a mecanism to send the user log to a webservice like the Windows bug report service.
It very much depends on the type of application that youre developing.
if its an mvc / mvp based architecture then your model, or most of it at least, will be on the server, and this is where most of your exceptions will be thrown i would imagine, so you can log them there and choose to display a message to the user or not.
for exceptions from the client you may want to know the details so just send them back.