I'm accessing Azure storage (table) from my windows phone azure app, using System.Data.Services.Client dll, via DataServiceContext.
My problem is that in my data classes I can't use IExtensibleDataObject as it's not supported in Silverlight.
Applying XmlSerializerFormat attribute also doesn't affect it, seems like it is ignored when using data services (Fiddler shows that the data is not really in XML format).
Is there a way I can prevent my app from crushing each time a new field is added to the table?
The type IExtensibleDataObject isn't available in the Silverlight Windows Phone version of WCF. If you have an error regarding this type, you should be able to regenerate the proxy class.
You can regenerate your proxy class by using the "Add Service Reference" option in the WP project on Visual Studio.
You can also use the Windows Phone service utility. Mine was found here:
C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Tools\SlSvcUtil.exe
Related
This question is strictly related with Windows Forms as my task is to do this inside a SAP Business one addon using C#. My requirement is to alter some configuration values stored in a Web.Config file of a related wcf service hosted in IIS. I need to get the IIS folder path (even the default path could be like "C:\inetpub\wwwroot", looking for a way to get it without hard-coding it) inside the SAP B1 form (Think as inside of a Windows Forms).
I've tried out the suggestion posted in the Getting IIS Application filesystem path thread.
string apPath = System.Web.Hosting.HostingEnvironment.ApplicationPhysicalPath;
Even if I added the System.Web reference to the project it gives me a null value, and I cant add the System.Web reference specifically to address this issue.
Also I've found Environment.SpecialFolder enum usage on MSDN but even it doesn't list IIS physical folder.
Environment.GetFolderPath(Environment.SpecialFolder.System))
Can someone suggest a workaround for this scenario? Even getting this value from the system registry would be ok.
You are trying to access the web application configuration information from IIS. That means you will need a library such as Microsoft.Web.Administration from Microsoft (part of IIS),
https://www.iis.net/learn/manage/scripting/how-to-use-microsoftwebadministration
or its open source equivalent from Jexus Manager,
https://www.nuget.org/packages/Microsoft.Web.Administration.Jexus
So here's my question how can i save to local database in Windows Phone 8.1 Universal without using external libraries.
So answer install/add nuget package is not an answer.
I'm creating library and as company specified i can not use any libraries, tho i need to save some of user data to database, as this data might be even few thousand records i don't want to think about saving it through IsolatedStorageSettings.ApplicationSettings,
In my old project(8.0) i used LinqToSql, so bonus points if this wouldn't need from me to change too much code.
You can keep using Linq To SQL with phone 8,1 Silverlight app, but I do not know of any in-the-box solution with 8,1 Universal
I am trying to publish a simple windows form application created in visual studio 2013 community edition, to a public storage container I have created in my windows azure account (currently this is a 30 day free trial account). The aim is for me to be able to have a user click on my web site and download the application as described here;
http://blogs.msdn.com/b/avkashchauhan/archive/2011/05/09/how-to-deploy-clickonce-application-using-windows-azure-storage-in-very-simple-steps.aspx
This is known as "click-once deployment" which sounds nice and simple, however I am having problems.
Basically when I try and publish to my container from the VS IDE (as described in the link above) I get an error suggesting I need to use some other method that uses ftp. Please see the screenshots below - any help on this issue would be greatly appreciated (i.e. if an ftp solution is required how do I go about this from the VS IDE).
You cannot publish directly to blob storage from Visual Studio. You have to publish locally and then copy the files to Blob Storage. When you publish, there should be a place to put "where the files go" and a place for "installation URL". You put the blob storage URL in the installation URL field, and "where the files go" should be somewhere local that you can find them.
Check out this blog entry. If you're going to do this going forward, this blob entry may also be helpful to you, to make it easier to copy the files to blob storage.
Can anyone describe to me the exact steps in displaying a SQL Server Report hosted on the report server (Remote mode) in a customized webpart? I realize that there is an out of the box web part that comes with SSRS but I want to be able to have already configured webparts that display specific reports available for users to add in their edit site modes. Essentially, the goal is to have a report such as 'Assigned Hours' as a web part itself, and anyone interested in displaying Assigned Hours need only click on Site Actions, Edit Page, Add Web Parts, and choose the Assigned Hours Web Part. No need for configuring a report server url or report path. Also, for certain reasons we would like to continue running the report server in native mode so Integrated mode with SharePoint is not an option.
So, below is a summary of my situation and what I have already tried:
Environment is WSS3.0, Microsoft SQL Server 2005
I have created a .net webpart and am attempting to add an instance of the ReportViewer control to the webpart. I have set to run in remote processing mode and have extended the abstract IReportServerCredentials class to handle the authentication.
I have made sure that the assembly is set to AllowPartiallyTrustedCallers
The project compiles fine. I place the dll in the correct wss bin folder for webparts.
When I try to view the webpart I get the site error message 'That assembly does not allow partially trusted callers.'
I've read things about registering my assembly with SQL Server, which I have tried with the CREATE ASSEMBLY SQL syntax, but that I am getting an sql query error saying that the there is already a reference to another assembly and that it can not find it in the same location.
Honestly, I don't really know enough about SQL Server and reporting services to know if I am close to getting it to work or if I have everything set up completely wrong in the first place. I have made custom webparts before and successfully deployed them to the site, so I know the problems lie in my ignorance of the SSRS and SQL Server. Has anyone else accomplished what I described early before? Thanks in advance!
I suggest using an ASP.NET ReportViewer control in your web part. These controls allow you to customize all parts you mentioned and are fairly easy to use and set-up. The one thing to watch for though with this control would be browser compatibility. Out of the box, it doesn't work too well with Firefox or Chrome. If you wanted though you could attached to the Reporting Services service which would give you the data you want back, then write a template-able control that used that structure to output the data. That option is much more complex, but allows for the format to be defined by the web part, rather than the report.
Currently I have a working Silverlight application that uses .Net RIA Services.
It's structure:
Client-side
Application.Client.UI.dll (Xamls and
basic UI stuff)
Application.Client.BL.dll (Contains the Link to RIA and most of the business logic)
Server-side
Application.Server.Data.dll (Server-side dll that holds the Entity-model and it's generated domain service)
Application.Server.Web.dll (Only the ASP.net hosting container, which references the
Application.Server.Data.dll)
I placed most of the business logic on the client side (Application.Client.BL.dll) for better user-experience (fast reactions) and to free up server resources. My challenge is now to re-use this client-side dll including it's RIA data access capabilities, in a server-side windows service. I'm wondering, is that possible at all? Is the Application.Client.BL.dll still able to consume the existing RIA service, or does that dll require the Silverlight runtime to identify/locate it's service target, and therefore will not work anywhere else.
Curious for your answers
You really shouldn't put any business logic on the client, the guys in security and / or architecture will hate you for it ;-). Furthermore you can't use Silverlight assemblies in ASP.Net or Desktop projects and vice versa. If memory serves correctly, Silverlight uses an entirely different CLR altogether.
I encountered similar needs when working with compact framework assemblies I also wanted to compile for the full framework. I'll describe how I would work around this scenario.
If there exist any issues referencing the Silverlight assembly, consider building two projects as follows:
Project #1 would be your Silverlight library, and should contain all the source files you want to use on the client.
Project #2 would be your Windows Service. Instead of including source files directly, use the "Add Existing Item", find the original source file in project #1, then (and this is the magic), drop down the Add button to choose, instead, choose "Add as Link".
By including the source file as a link, you retain the ability to maintain your source code in one location, but add the ability to compile your code for multiple frameworks. As long as the code relies on assemblies available in both the Silverlight framework and the full .NET framework, then you're money.
Now, regardless of whether you choose a multi-project approach, know that domain context classes have additional constructors that allow you to specify contextual information, such as the URL, for the corresponding domain service. I use the following code in one application to construct a domain context for a domain service that provides personnel data:
var context = new PersonnelDomainContext(
new Uri(ConfigurationManager.AppSettings["PersonnelServiceUrl"]))
In this case, the URL looks something like:
http://website-url/Services/Hyphenated-Namespace-PersonnelDomainService.svc
Of course, when writing a Windows Service, nothing is stopping you from referencing the server-side domain service (not context) assembly directly. With the domain service in hand, you can instantiate a service instance without all the additional configuration and without the additional network XML payload. There are trade-offs to this approach, such as forfeiting centralized configuration management (such as connection strings), but depending on your circumstances, you may find the trade-offs to be worth it.
Happy coding!
Have you considered using fork-reuse? Take a look at:
http://sharednow.blogspot.com/2011/05/its-not-just-reuse.html