I've found a very small sample showing Silverlight SQL connection (http://www.codeproject.com/KB/silverlight/CntDbSlght.aspx), I've tested it and it works fine on local system, also I've changed its connection string so that it shows data from my remote database, but when I upload files to my host, I cannot see any SQL data, it seems that something is broken, how should I configure my web.config?
What are CrossDomain.XML and ClientAccessPolicy.XML files? should I upload them? If so, where should they be? How should I bind my service? what am I doing wrong? I click on VS2010 publish (in build menu) and select file system, then I upload all files existing in this folder, I use C#.
If you are trying to access an external Silverlight web service from your local dev environment you certainly need a ClientAccessPolicy.XML file on the website. This tells the site services where requests can come from (normally only from the same site the SL app was run from).
Your ClientAccessPolicy.XML file needs to go into the actual root of your website i.e. 'mydomain.com/ClientAccessPolicy.XML.
*Note: You do not also need a CrossDomain.XML if you have ClientAccessPolicy (which is the SL specific one). CrossDomain.xml is an older flash compatibility file that sometimes exists on sites.
Related
we are working on a WPF application which we want to publish as a click once smart client application.
We are able to publish the application on local machine using Visual Studio 2012 and configured it in IIS.
Now we want to upload the published smart client installer to windows Azure Virtual Machine with Windows Server 2012 and IIS 8. We cannot upload the locally published components as the URL configuration in the manifest and deployment file is that of local server. We tried to edit the entries using text editor but once we do the editing the files become unused and it shows xml parsing error when we try to install from the location.
we tried to publish the application direct to the Virtual Machine but it shows an error as Front Page Extension is needed in IIS. We tried to find Front Page extension but couldn't find an version for IIS 8 in Windows Server 2012.
Can any one help us to publish the application in Azure Virtual Machine.
The problem you are having has nothing to do with Azure per se.
In the first case (of editing the XML files), you can do that but it's best to use MageUI to do the edit, because you can then re-sign the manifests. If you just edit the files, it messes up the security on them, and they will not work (as you have found). If you want to edit them with a text editor, you can do that, but then you must re-sign them (using mage); you can create a script to change the installation URL.
Or you can use MageUI. You need to do it in this order:
Open the application manifest in the versioned folder and then save it, re-signing it with your signing certificate.
Open the deployment manifest (yourapp.application) in the top deployment folder. Change the Start Folder to be the right Installation URL. Go to the "Application Reference" tab and re-select the application manifest in the versioned folder. (I know, it hasn't changed, but trust me, you have to do this.) Save this manifest and sign it with your signing certificate.
Copy the deployment manifest from the top folder to the versioned folder. It's always good to keep a copy, so you can go backwards a version if you need to.
NOW you can copy the files to your VM and they will work fine.
In the second case, the Front Page Extensions are required if you are using HTTP to publish the application, yet they are no longer available past about Windows Server 2008(?). So don't use HTTP. Use FTP. Set the publish file location using FTP, like ftp://myserver.mycompany.com/myfolder and set the Installation URL to the HTTP equivalent of it. Then publish it. It will put the files on your VM (assuming FTP is enabled on both sides), and the HTTP link should work.
By the way, you can also host your deployment in Azure blob storage. It is dirt cheap, and you can use something like Cerebrata Cloud Storage Studio or even write your own code to publish it (which I did). This article explains how to put the files out there, what the MIME types need to be, etc. If you do this, then it will work even if you need to replace your VM or redeploy it or the VM becomes unavailable for some reason.
here is a reference to Avkash Chauhan's blog post explaining in detail How to deploy ClickOnce Application using Windows Azure Storage in very simple steps?
http://blogs.msdn.com/b/avkashchauhan/archive/2011/05/09/how-to-deploy-clickonce-application-using-windows-azure-storage-in-very-simple-steps.aspx
He also gives an code example of a windows form (using Wpf) that he shows how to deploy on azure using one click deployment.
hope this helps
The scenario I am trying to create is to have my Silverlight Website on one domain and my file server (for media files) on a different server. I want to allow my users to upload files to the file server from the website.
The problem is I am getting a generic "Security error." reported back in the inner exception message in my code. The main exception message is blank.
I have set all access right to the physical folders (Windows Server 2008). I have created wide-open clientaccesspolicy.xml and crossdomain.xml files.
I am using an .ashx handler for doing the actual writing to the hard drive. I have tested it locally on the file server machine and it works fine.
I have root level access to both servers so I can make any changes required.
I'm not a Silverlight programmer, but I might be able to help here... Browser security prevents pretty much any cross-domain actions like this. It's to prevent phishing.
What you could do to get around this is to create another hostname on the same domain as your webserver and proxy any requests on your webserver to your file server. That would get around the cross-domain problem.
I have several WCF services.
When I check them on the server (example: ServiceTest.svc?wsdl), than I see an xml file with info about the wcf service. So the services works fine.
I have a Silverlight application on a different server.
I get the 'famous' crossdomain error.
When I place a clientaccesspolicy.xml in the directory with the WCF services, the problem remains.
Is it possible that with shared hosting, the security isn't high/low enough?
thanks,
Filip
The XML file must be placed in the root of the domain. Usually you have to put them into the inetpub/wwwroot folder, instead of into the folder with the WCF services.
Depending on how your provider implemented the shared hosting, I'm afraid you'll have to ask them to support cross domain access and put the XML files into the root.
I am not sure but I think it also could work to register your own domain that points to the folder you want to use as root, and put the XML files there. The clients must then use the server URLs with your registered domain of course.
One of the best tools for issues like this is Fiddler(or some other web debugging proxy). Looking at the network calls, you can see the address where the browser is looking for the clientaccesspolicy.xml file and then make sure you drop the file at that location. If you're not seeing this call or you're seeing it and the file is already there, you can move on to other issues (a bug in the webservice or the calling code).
I made a simple Silverlight app, with a web service calling a database, and got it to work on my development computer.
When I published the web service project to IIS, on the same computer, and accessed the Silverlight app from IIS using http://localhost/SilverlightTest/, I could see the Silverlight in the page, but the call to the web service was not working.
So I added the file clientaccesspolicy.xml in several places. All of the instructions say to put it in the root directory, so I tried:
c:\inetpub/wwwroot\ Did not work
c:\webs\SilverlightTest\ This the folder to which I published the web service project, including the xap file. But did not work
c:\webs\ Just a guess, but that did not work.
Then, in VS, I added the file to the web service project, and that added it to the folder where the web service project is stored c:\work\Silverlight\TestWCF\TestWCF.Web\ . When I opened the page in Firefox from IIS, the call to the web service now worked. Apparently, the Silverlight application is calling the web service in my development folder, not the service in the IIS virtual directory c:\webs\SilverlightTest\ (He call to the web service did not work when I opened the page from a different computer in the workgroup)/
Why would the Silverlight application call a web service in a development folder? Shouldn't the web service be in the virutal directory to which it was published? How can I resolve the confusion?
Here is the configuration in my ServiceReferences.ClientConfig file
<client>
<endpoint address="http://dellnov2006:2753/SimpleWCF.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISimpleWCF" contract="SimpleWCF.ISimpleWCF"
name="BasicHttpBinding_ISimpleWCF" />
Any help, explanation, or pointers to relevant articles would be greatly appreciated. An article explaining how Silverlight apps call web services would be greatly appreciated.
Thanks
Mike Thomas
In your config file, the endpoint address is http://dellnov2006:2753/SimpleWCF.svc
So it seems that you are trying to connect to that address.
Before you publish the application you must modify that address to http://localhost/Service/SimpleWCF.svc or something to point exactly to your service.
The clientaccesspolicy.xml must be in **c:\inetpub\wwwroot** But you need this file only if you will access the service from different host that it was downloaded. I don't think you need it in your case, if you want to use localhost on the local iis.
The address in the ClientConfig is the address of the service you "Added Service Reference" against. As you noticed, it's not a relative path. To overridde this behavior, specify the URI of the address in the constructor of the Service client.
Also, you really need Fiddler. You'll love it. It helps with these issues as well as cross domain issues.
Many thanks djjoyro. You were right. Changing the config file to:
endpoint address="http://MachineName/SilverlightTest/SimpleWCF.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISimpleWCF" contract="SimpleWCF.ISimpleWCF"
name="BasicHttpBinding_ISimpleWCF"
worked, and without a client access policy file. This also worked when I accessed the Silverlight app from other computers in the workgroup.
I also tried using localhost instead of the computer name, but I did have to use a clientaccesspolicy file, and I could not access the web service when using other computers in the workgroup.
There is a lot more I need to know about this, but at least deployment is now working after several days of struggling.
Mike Thomas
Late to the party, but I will add that if your binding address includes a port #, then you are still using the Visual Studio web server. http://dellnov2006:2753 is a dead giveaway that you still using the VS web server and not IIS as you intended.
We have a WPF XBAP application that we want to change the configuration on the server after it is deployed. Since the config file is embedded in the deployment files, how is this possible?
For example, we want to change the database connection strings the deployed app is connected to or we want to update the WCF service binding settings that it is connecting to? We want to update the config file on the server and not have to recompile and redeploy each time.
Thanks!
In the SDK directory is a program called MageUI.exe. This program lets you create and edit application deployment manifests. You can update your config file, then use MageUI to edit your deployment manifest and import the new configuration file.
Depending on the size of your application, it may just be easier to hit Publish in Visual Studio than go through the effort of using MageUI and editing deployment manifests.
Alternately you can have your application look on your deployment server via an HTTP request for a config file (renamed to something other than .config, since ASP.NET by default blocks those files) for the updated configuration.