I'm trying to run a XBAP application from behind a proxy server, the first time I load it it works fine. The second time I get a generic "WPF Host has failed" Error message. The xbap file itself downloads correctly, it just fails to execute.
Any ideas?
ok, problem solved. Caused by a ssl cert intercepting corp proxy that was rewriting the certificate which meant the application no longer trusted it.
Related
i am Working on Silverlight5 Application. We have to Open one Exe from Client Pc. As We try with In Browser Trusted Application and it's work within the Localhost but we try to using IP address instead of Localhost then again application unable to open Exe.
We try to sign Application with Test Certificate and install in Trusted Root Certification Authorities And Trusted Publisher
Now it was working with Localhost as well as IP address but within a My Pc but Not working in Network Pc.
Please Suggest me, what things i am missing or what i have to do
i am got my question's answer, the problem with the test certificate,when i am using a actual certificate (from verisign) my application is working as per our expectation, it's open a exe from client machine.
I'm trying to get a silverlight program to install locally and still be able to access wcf data services over ssl. When I run the application in browser, everything works fine. When I run the application out of browser without ssl everything works fine. When I run the application OoB with ssl, I get a "Not Found" error. When I run fiddler and retry, everything works fine. I'm guessing that the program isn't correctly decrypting or sending the ssl traffic when OoB since when fiddler does it for it, the application works fine. I'm also not hitting any exceptions or break points on the server when I attach VS to it (this makes me think there is a problem with the send). Any ideas on what my next step should be? Also, I am using a self signed certificate, could this be an issue? THANKS!
Has anyone found a resolution for this issue? Or does silverlight just not work with SSL in OOB mode??
See this link for reference:
http://msdn.microsoft.com/en-us/library/dd920295(v=vs.95).aspx
basically it says:
Client certificates are supported by the browser stack, but not by the
client stack. And there is currently an issue that (at least for our
application) prevents client certificates from working even with the
browser stack if you're in trusted out-of-browser mode.
I have a Silverlight application that does two things:
1) connects to a WCF server (hosted inside a WPF app on a different PC) and sends small packets of info (using PollingDuplexHttpBinding if it matters)
2) sends a web request for get an XML file from a different remote server for parsing
At dev time, its all running locally, but in production it will be a scattered deployment each running on a different server.
But I am running into issues that I think are related to the clientaccesspolicy.xml and crossdomain.xml files
My Silverlight app runs at a random port (as defined by VS2010)
The WCF service runs at: http://localhost:80/MyService which I can connect to just fine from the SL client (I have got a clientaccesspolicy.xml file on the WCF side)
But, and here is the part that is failing, when I send a request for the XML file, which is http://localhost/MY_TEST_SITE/thefile.xml I get the error:
The remote server returned an error: NotFound.
but I put that address into Firefox I can see the XML file no problem. I do have a clientaccesspolicy.xml in that location, which I think is correct.
If it was a cross-domain issue should I be getting a security exception here? instead of a not found exception?
How can I debug this?
Its ok I figured it out, I had something blocking on port 80, which was causing a whole heap of issues, once I switched that off, it was back to normal
I am one of 2 developers on a silverlight project that is hosted online. The problem is that i seem to randomly have problems with our webservices not working (This never happens to my colleague).
Using firebug, i had a look at any problems that it was reporting and i found this:
GET clientaccesspolicy.xml 404 not found
GET crossdomain.xml 404 not found
Any ideas why only i have a problem with like this?
We have both cleared out our cache and recycled the application pool of the webserver... no joy.
Thanks,
Kohan
So the webserver intermittently returns 404 errors on the policy file? What version IIS?
If your colleague never gets the error, compare the request headers between his system and yours to be sure there isn't something weird going on.
If the policy file is hosted by a provider and you're getting intermittent 404 errors you should put in a ticket with the provider.
This happens when the client attempts to connect to a domain on which it is not hosted. The policy files are used to grant access to that server from the SL client.
Are you both running the client from the same location? Double check your proxy settings and hosts file too.
Found out the problem came when accessing the site without typing "www."
I should have known to check that first. :(
I have created an application that can save data both local drive and isolated storage. Then I have tested it by deploying via ClickOnce with FullTrust. This worked correctly, but when I set it to PartialTrust (Internet zone), the application cannot start up.
How to solve this problem?
I have tried to create empty form Windows application and then deploy using PartialTrust, it still errors when I run the application.
ClickOnce applications do not need full trust permissions to write to isolated storage. However, applications do need full trust for regular file I/O. So I'm guessing that your application will have to request full trust to work.
However, I'm not sure why your empty application won't work with partial trust. What error message do you get?
Are you using the SaveFileDialog? From memory, this throws a UIPermission exception for a partial-trust ClickOnce app deployed from the Internet zone. If that's what is happening, you need to change your app deployment to request this specific permission.
UPDATE: If you do a debug build, the exception stack trace will give the line number that caused the security exception.