I've been developing a game using Silverlight 4 and silversprite (http://silversprite.codeplex.com/)
This game is HEAVILY content dependent, using a lot of audio and images. My content folder is around 90 mbs worth of stuff.
And because of that, my XAP file is around 60 MB, and takes 5 minutes to download from the website before any user can start playing.
I am using Visual Web Developer 2010 to create my site and load the XAP. Is there a way where I can take content out of my XAP and put it in my ASP.net site project? Or perhaps upload my content files to the site's storage?
This would make my XAP file much quicker to download.
Anyone have suggestions?
Thanks!
Yes, include in your XAP only content you need for the initial screen. Place other content you need in other XAPs (if you need to and understand the manifest xml) or just plain zip files would do. Perhaps a Zip for each "Level" or whatever.
You can download the Zip with WebClient and then use StreamResourceInfo and Application.GetResourceStream to access content in the zip file.
This blog although aging a little now still carries the basic idea and is still fundementally the current technique to use.
Absolutley its called Application Library Caching. Ive used it very successfully its now a standard operating procedure, particularly nice is its application with resource assemblies.
straight from msdn ...
Resource files are typically any non-executable data file used by your application, such as image, audio, and video files. A resource file can also have specific meanings in certain contexts. For example, in the context of application localization, resource files refer to .resx files, which you can deploy in localized satellite assemblies.
it continues with some really useful info
With Silverlight, you can deploy
resource files in the following ways:
•As individual files in the
application package.
•As individual files that you retrieve
on demand.
•As files embedded in an assembly in
the application package.
•As files embedded in an assembly in
an external library package.
•As files embedded in an assembly that
you retrieve on demand.
which is what is suggested in the other answer(s)
Related
I have an ASP .NET Web Site Project that is being moved into TFS. There is a folder that is used for user uploaded files (e.g., company logos, excel spread sheets, etc.) that need to be kept. I'm trying to figure out a good way to manage these files without placing the folder in TFS (it's really big), and make it easy for new developers to grab the folder structure to their local machines for development.
I was thinking of doing the following and was wondering if this is a good way of doing it, or if there are better alternatives:
Create a script which will, when executed, create the folder structure of the storage folder. This would be placed in source control.
New developers could grab this file and execute it on their local machine.
To make sure the folder is added to source control, get the developer to remove it from their local project.
Store the folder on a NAS - no need for the files to be part of the source-controlled code.
This is my first time localizing or globalizing anything, so I'm learning on the fly. I'm using Visual Studio 2010 / net4.0 / vb.
As a result of moving my pages into 4 language .resx files located in my App_GlobalResources directory. I have LocalizedText.resx, fr., .de, and .es-mx.
I'm just about done with it. But my .resx files are about 120 KB in size. I don't want to increase loading time, especially on slow or old computers. Is this too much? Is this not (recommended)? I suppose the size has to go somewhere, whether it's in the aspx file or resx file.
I just want to make sure I've been doing the right thing.
On an ASP.NET site, the performance will not be so heavily impacted based on the client machine performance. The .resx file will be parsed and compiled into HTML on the server before being sent down to the client. The resultant page will be the same size, regardless of how many records you have in the resource file, so the client will not be affected.
That being said, 120KB is not excessive. Depending on the size of the sever, you can get away with much larger resource files, but your performance will vary.
The size of the .resx file does not affect the size of the page sent to the client.
All of the strings used by the page will be included in the HTML, but if a resource isn't needed it won't be sent.
I have worked on localized applications that included dozens of resx files, totalling megabytes of data, so 120k is not going to be a problem.
I'm a newbie with ASP.NET web applications. When I create an ASP.NET web app project, there's a file called resources.resx in the folder My Project. Working in my computer I can access this file and its content without any problem. But when I deploy the application I can't access this file. I've tried copying the file seperately, and the folder (My Project) seperately, with the file in it, but no luck. Is there a way to achieve this?
PS: I've read something about implicit localization and explicit localization but I'd like to know if it can be done this way.
It's embedded into your DLL when you build (compile). So you can't change it when it's deployed.
If you want to see it in your DLL, you'll have to use a tool like Reflector, dotPeek, etc.
You can read more on resources here, starting from the 'Compiling Resources into Assemblies' title (as you know how to use them by now).
Well my suggestion is to use global and local resources.
In production you'll have resx file stored in:
App_GlobalResources: available in all application
App_LocalResources: one for each folder you want resources.
They are XML files visibile and editable.
I use it to allow me to modify string localization resources without recompiling and deploying.
And you can also give a web interface to the end user to allow him to self translate and localize strings at runtime.
We have so, so many RESX files in our ASP.NET 3.5 web application (for localisation purposes) and it's making code changes very slow; every time it runs for the first time all the symbols are built for the re-compiled RESX files.
Ideally I'd like to store these files in an external assembly and create a ResourceProvider that acts as a bridge.
That way the RESX files won't be affected by each subsequent compilation of the web app.
I also don't want to reinvent the wheel; someone must have done this before - but I can't find anything on it!
Actually it looks like reading through this article is going to be a good bet:
http://msdn.microsoft.com/en-us/library/aa905797.aspx
But I'll still hold out in case someone has an example!!
We have several fairly large JavaScript files embedded into a single script resources DLL. This is then consumed by multiple projects by way of a reference and page includes via the ASP.NET script manager. This keeps things nice and neat within our ASP.NET pages and requires very little work to integrate into new projects.
The problem is that some of these script files are quite larger (approx 100KB) and take time to download. By running minify on them before embedding this is reduced down a lot (around 70KB) but not enough. What we would like to do is GZIP the files before they are embedded. However, just gzipping the files causes syntax errors as the content is not unzipped. There is a content type "text/javascript" applied in AssemblyInfo when the resource is embedded but we can't find a way to specify content-encoding.
Is there any way to make this work without having to write a httpmodule/handler (which would mean changing the config for all consuming projects)?
Okay, so it looks, from many different attempts, an absence of answers and a lot of Google searching, that the HttpModule is the only way to approach this. In an attempt to keep this easy to configure I've setup an HttpModule inside the same dll containing the script files as below.
Simplified DLL Structure
\ScriptMinified\*.js [Embedded Resource] (Minified Only)
\ScriptCompressed\*.gz [Embedded Resource] (Gzipped and Minified)
\ScriptDebug\*.js [Embedded Resource] (Raw uncompressed and commented)
MyScriptManager.cs
MyHttpModule.cs
The only additional work is an entry in the consumer's web config to enable the module. Plus I've made the initialize call, in MyScriptManager, that includes the script tags, detect the presence/mode of the new http module and serve gziped, debug or minimized versions as required. This means we don't have to recode or configure any old projects for them to work so achieves much the same result.