I have an issue that is quite confusing for me and was hoping somebody might have some helpful information.
I have a Silverlight 4 app running on Azure (latest SDK). The Silverlight is a typical application using WCF Data Service calls to get and write data to a database. This all works fine on a PC. However, when running on a Mac, any browser, it works for 95% of the application. However, there is one piece that does not work.
My Silverlight application takes information entered into a form, formats a WCF Data Service call to get a record count from a Lucene Index file. The service gets the index count, packages it into one of my defined entities (using the Visual Studio Entity Data Model) and sends the object back from the service to the Silverlight application. The problem though is that it is not returning the correct number. My debugging seems to indicate a 0 is being returned. Again, it only does this for a Mac. The correct number is returned for any browser on any PC. Again, on top of that every other web service call I make from my Silverlight application is returning correctly on the Mac.
Does anybody have any ideas as to what might be happening? Please ask if I have left out any detail.
Thanks
Wanted to update with my solution in case anybody else ever runs into a similar issue.
Data from two of the fields on the form are dates (start and end dates to be specific). I was reading these values, extracting the year and then creating my own DateTime object. This is where the problem occurred. It appears Mac Silverlight formats the DateTime object differently than the PC Silverlight. The PC Silverlight was formatted correctly (1/1/2011 0:00:00) whereas the Mac Silverlight formatted incorrectly (1/1/11 12:00:00 AM -5:00) based on my time zone.
My solution was to format the date myself into a string as it needed to eventually be in string format for passing to the Web Service that queried my Lucene indexn anyway.
Related
I have found many samples and examples of silverlight applications that use EF for their data store. Why is it that every single one uses a database full of data and shows how to edit/save? I'm having problems setting up an application where I (want to) have no data to start with and would like my user to then populate the data store. Everything works fine when data exists but I get into all sorts of null problems when I want to start with no data.
Just saying...
ANyway, my question: Does anyone know of any tutorials that demonstrate code where no data yet exists?
Thanks!
(Sorry for my bad english)
I suppose you are using RIA Services? That's the easiest way to develop an SL app with EF. It should make no diference between having data or not, the RIA Service returns a collection with 0 or more itens, you bind that with a DataGrid and are done. Here is a link with source code of a full aplication, that starts with no data: http://johnpapa.net/wcf-ria-services-hands-on-lab - What is most important to understand is the asynchronous nature of RIA Services. Keep that in mind, take a look and try the code.
If you have more questions, try to be more specific about the exact errors or problems you are facing, it would be easy to others try to help you :)
I am re-making a Console game, that my boss made a considerably long time ago, in Silverlight. It's totally text based. In the Console version, each computer that had it installed had its own map, which was divided into a grid of rooms.
What I want to do is make the map global; when anybody runs the Silverlight version, they will all see the same map. There is no changing that goes on in the map, only new rooms being added to the map.
So, currently I'm storing all the data in IsolatedStorage, which is obviously not global. How should I store the data and retrieve it so that everybody playing can see the same map?
If it helps any, the server that it will be hosted on is a linux server, and has MySQL.
See this answer to a person who was trying to do something very similar (he wanted high score data, you want map data): High Scores self contained in .xap
The fact that you are running a linux server complicates things a little - instead of running a WCF or asmx service, you could consider a java based web service, or just make a normal HTTP page that queries the MySQL database and returns data which your Silverlight app can request and consume (this is still a "web service", albeit a very primitive one).
I have a very critial business application presently running using Winforms.
The application is a very core UI shell. It accepts input data, calls a webservice on my server to do the computation, displays the results on the winforms app and finally send a print stream to the printer.
Presently the application is deployed using Click-once.
Moving forward, I am trying to contemplate wheather I should move the application into a Silverlight application. Couple of reasons I am thinking silverlight.
Gives clients the feel that it is a cloud based solution.
Can be accessed from any PC. While the clickonce app is able to do this as well, they have to install an app, and when updates are available they have to click "Yes" to update.
The application presently has a drop down list of customers, this list has expanded to over 3000 records. Scrolling through the list is very painful. With Silverlight I am thinking of the auto complete ability.
Out of the browser - this will be handy for those users who use the app daily.
I haven't used Silverlight previous hence looking for some expert advice on a few things:
Printing - does silverlight allow sending raw print data to the printer. The application prints to a Zebra Thermal label printer. I have to send raw bytes to the printer with the commands. Can this be done with SL, or will it always prompt the "Print" dialog?
Out of browser - when SL apps are installed as out of browser, how to updates come through, does the app update automatically or is the user prompted to opt for update?
Printing -- using the PrintDocument API your user will be prompted for a print dialog. Currently using that API there is no way to suppress this. It isn't ideal for high-volume thermal situations (like pharmacies, shipping warehouses, etc.). You could use the trusted application mode and peek out into COM and do whatever you want with the printer.
The update happens when the application asks for it. There is an API to use and, once called, if an update exists it is downloaded -- no prompt to the user as an option. If an update is found you can alert the user to restart or that on the next restart they will have the updated application.
Autocomplete is not something that can only be done in Silverlight. Your ClickOnce app is already out-of-browser. And printing via raw bytes to a thermal printer is something that would not be easily engineered in Silverlight.
Not trying to sound negative, but in sum it sounds like you're better off simply working on enhancing the app that you already have.
What are my options for printing in Silverlight 3? Assume I have this awesome Silverlight application/control that creates a graphical display of some data. Now the user wants to print it.
I have considered a few options but I have yet to test any of these. Before I do that I would like to get some feedback on how it can be done.
Use the browser printing capabilites. In my experience this is does not provide a useful print, but perhaps with some interaction between the Silverlight host and the browser it can be done?
Use WriteableBitmap. The image can either be written locally, but this requires interaction from the user, or sent to the server where a suitable file (e.g. PDF file) can be generated and then sent back to the browser. Unfortunately you now get the overhead of sending the image twice across the network and increased complexity on the server side.
Send XAML back to the server that is then rendered in a WPF application running on the server. The result is the sent back to the client. I'm not sure if this is possible at all however, but if it is the network overhead is less than in option 2. Unfortunately, the complexity on the server side is even higher.
Wait for Silverlight 4?
One thing I have considered is that my awesome control probably will have a ScrollViewer at the highest level, but the user will want to print the entire content of the control, not just whatever is visible inside the bounds of the ScrollViewer. How can I handle this added complexity?
In all seriousness, I think your best option is to wait until Silverlight 4 if your client can wait that long. I've seen a good bit of buzz about SL 4 supporting printing on twitter, though it's not official. I'd wait until PDC in a few weeks and see if any Silverlight bits trickle out to support printing.
Take a look at SmartPrint for Silverlight 3: http://www.smartwebcontrols.com/SmartPrintDetails.aspx
TBH I wouldn't use any of those options:-
Printing from the browser. Fine if you are printing say a chart or something else that scales well on a single sheet of paper. Rubbish for anything else especially where you have scrolled content.
WriteableBitmap. I can't see a client-side only solution being acceptable to the user "Please save this and then print it" message. It could be made to work bouncing off the server but would be bad for bandwidth use (bandwidth is import right? because in a well-connect intranet you wouldn't using Silverlight?).
Sending XAML to server for rendering. Really awkward it would be WPF XAML not SL XAML, where and how would you do the binding, why send XAML at all, since the server needs to be pretty much clued in on this so why can't it hold the XAML needed as well. Or were you thinking of sending just pure XAML with all the data needed? Still its a lot of plumbing needed in the SL that isn't actually related to SL.
Use Silverlight 4, its possible that in the not to distant future this would be the correct no-brainer choice (personally I wouldn't hold my breath) but right now SL4 doesn't exist.
A 5th option
Place report generating code on the server and have the Silverlight app inform the server of the data set required (not necessarily posting the data merely the criteria needed to access the correct set). In my experience direct prints of GUIs aren't particularly satisfactory when the user really needs a good printed form of the data.
Its true that at times the user just wants to quickly get some offline access to a grid of data as it looks there and then. In that situation users often find an export to spreadsheet compatible file preferable to printing, which would be possible from SL.
Something akin to number two is pretty much your best bet and is what I've seen done for printing in most Silverlight apps so far.
You can have the app send content for printing back to the web server (i.e. a new handler or query string parameters to a printing page) and pop up another page for the user to print web content from, or you could allow the user to download a file and have them print that.
Sliverlight 3 does not support printing.
If you can wait for silverlight 4, they have given it "high priority"
If not use Writeablebitmap: http://www.andybeaulieu.com/Home/tabid/67/EntryID/161/Default.aspx
First off I understand that it is a horrible idea to run extremely large/long running reports. I am aware that Microsoft has a rule of thumb stating that a SSRS report should take no longer than 30 seconds to execute. However sometimes gargantuan reports are a preferred evil due to external forces such complying with state laws.
At my place of employment, we have an asp.net (2.0) app that we have migrated from Crystal Reports to SSRS. Due to the large user base and complex reporting UI requirements we have a set of screens that accepts user inputted parameters and creates schedules to be run over night. Since the application supports multiple reporting frameworks we do not use the scheduling/snapshot facilities of SSRS. All of the reports in the system are generated by a scheduled console app which takes user entered parameters and generates the reports with the corresponding reporting solutions the reports were created with. In the case of SSRS reports, the console app generates the SSRS reports and exports them as PDFs via the SSRS web service API.
So far SSRS has been much easier to deal with than Crystal with the exception of a certain 25,000 page report that we have recently converted from crystal reports to SSRS. The SSRS server is a 64bit 2003 server with 32 gigs of ram running SSRS 2005. All of our smaller reports work fantastically, but we are having trouble with our larger reports such as this one. Unfortunately, we can't seem to generate the aforemention report through the web service API. The following error occurs roughly 30-35 minutes into the generation/export:
Exception Message: The underlying connection was closed: An unexpected error occurred on a receive.
The web service call is something I'm sure you all have seen before:
data = rs.Render(this.ReportPath, this.ExportFormat, null, deviceInfo,
selectedParameters, null, null, out encoding, out mimeType, out usedParameters,
out warnings, out streamIds);
The odd thing is that this report will run/render/export if the report is run directly on the reporting server using the report manager. The proc that produces the data for the report runs for about 5 minutes. The report renders in SSRS native format in the browser/viewer after about 12 minutes. Exporting to pdf through the browser/viewer in the report manager takes an additional 55 minutes. This works reliably and it produces a whopping 1.03gb pdf.
Here are some of the more obvious things I've tried to get the report working via the web service API:
set the HttpRuntime ExecutionTimeout
value to 3 hours on the report
server
disabled http keep alives on the report server
increased the script timeout on the report server
set the report to never time out on the server
set the report timeout to several hours on the client call
From the tweaks I have tried, I am fairly comfortable saying that any timeout issues have been eliminated.
Based off of my research of the error message, I believe that the web service API does not send chunked responses by default. This means that it tries to send all 1.3gb over the wire in one response. At a certain point, IIS throws in the towel. Unfortunately the API abstracts away web service configuration so I can't seem to find a way to enable response chunking.
Does anyone know of anyway to reduce/optimize the PDF export phase and or the size of the PDF without lowering the total page count?
Is there a way to turn on response chunking for SSRS?
Does anyone else have any other theories as to why this runs on the server but not through the API?
EDIT: After reading kcrumley's post I began to take a look at the average page size by taking file size / page count. Interestingly enough on smaller reports the math works out so that each page is roughly 5K. Interestingly, when the report gets larger this "average" increases. An 8000 page report for example is averaging over 40K/page. Very odd. I will also add that the number of records per page is set except for the last page in each grouping, so it's not a case where some pages have more records than another.
We narrowed down the large PDF exports from SSRS and found 2 main culprits
1) Unless images are JPG or PNG colour type 3, they are expanded to BMP's See here
2) Unless you configure SSRS to behave otherwise (not recommended), then SSRS will embed fonts or font subsets into the PDF, unless they are one of the 5 'standard' PDF fonts.
Although none of the standard fonts (other than Symbol I guess) are installed on most Windows OS's out of the box, we've found that if you use Times New Roman, Courier New, or Arial then forward and reverse font substitution will take place.
The easiest way to convert your RDL's is to view them as XML and search and replace the FontFamily tags.
If you have to use a non standard font, then, you can still minimize the damage:
Use as few fonts as you can. Search through the RDL XML to make sure there aren't any redundant fonts.
Use TTF fonts if you use different sizes of the font.
Try not to mix normal, bold and italic variants of the font, else it will be embedded multiple times.
Does anyone know of anyway to
reduce/optimize the PDF export phase
and or the size of the PDF without
lowering the total page count?
I have a few ideas and questions:
1. Is this a graphics-heavy report? If not, do you have tables that start out as text but are converted into a graphic by the SSRS PDF renderer (check if you can select the text in the PDF)? 41K per page might be more than it should be, or it might not, depending on how information-dense your report is. But we've had cases where we had minor issues with a report's layout, like having a table bleed into the page's margins, that resulted in the SSRS PDF renderer "throwing up its hands" and rendering the table as an image instead of as text. Obviously, the fewer graphics in your report, the smaller your file size will be.
2. Is there a way that you could easily break the report into pieces? E.g., if it's a 10-location report, where Location 1 is followed by Location 2, etc., on your final report, could you run the Location 1 portion independent of the Location 2 portion, etc.? If so, you could join the 10 sub-reports into one final PDF using PDFSharp after you've received them all. This leads to some difficulties with page numbering, but nothing insurmountable.
3. Does anyone else have any other
theories as to why this runs on the
server but not through the API?
My guess would be the sheer size of the report. I don't remember everything about what's an IIS setting and what's SSRS-specific, but there might be some overall IIS settings (maybe in Metabase.xml) that you would have to be updated to even allow that much data to pass through.
You could isolate the question of whether the time is the problem by taking one of your working reports and building in a long wait time in your stored procedures with WAITFOR (assuming SQL Server for your DBMS).
Not solutions, per se, but ideas. Hope it helps.
Obviously, its a huge report, in fact it's closer to a 1.3 GB database, than a report.
Have you thought of finding a way to split it into multiple pieces and then combine them together? (use one of several different ways to combine PDFs listed on this site.)