There is a lot of action in the CSS/JS bundling+minification space with MVC4 and things like Cassette, but I can't seem to find one that supports uploading to a CDN natively.
We use Rackspace Cloud Files and it requires that we upload (via their API no less) our assets directly - it doesn't do an origin-pull.
Right now, we have MSBuild script that does this for us, but it is very difficult to maintain and work with.
If you could map a drive, I think RequestReduce MIGHT get you what you want out of the box. It performs bundling and minification at runtime and provides some configuration options that allow you to specify the drop location of generated assets to any UNC path. The intent of this config is for web farm scenarios that have a dedicated share for static assets. I'm wondering if this might work for you. It also exposes an interface that allows you to essentially take over the process of saving and retrieving assets from any durable store. It comes with a local disk store and there is a SqlServer store provided as a separate Nuget package. I've had others propose writing ones for Azure blob or amazon ec3. Its a bit involved but not too horrible. At any rate its free, it provides background image spriting and optimization which few others provide and there is another Nuget package that adds Less/Sass/Coffee compiling. Its used by Microsoft on alot of the MSDN/Technet properties.
I run the project and would be happy to answer any questions via the Github Issues page.
Related
Is it good practice to have a production (live) asp.net website that is also a working copy to push updates?
In general this is considered bad practice primarily because the source control repository contains the source whereas the production application contains the result. The two are kept separate for a number of reasons:
Security. If your source is on your production server, it's at risk of being viewed. Maybe this is a problem, maybe it's not. The safe approach is to just not have the source on the production server.
Performance. The result of building the source can be optimized for performance in ways that the source itself generally isn't. In a .NET application, for example, the production deployment doesn't contain debugging symbols. This may not be an issue in your particular application, but it's something to consider.
Multiple Results. Is your source an actual application, or is it information used to build an application? Can multiple versions be built? For example, in a .NET web application, you might have Web.config transforms. These are used at deploy-time to adjust the result of building the source. If the source itself is being used as the live application, these deploy-time modifications aren't available.
Others may be able to articulate this much better than I can, but in general it is considered bad practice, yes. Your particular application may be an exception to any particular reason or may not be meaningfully affected by any particular reason, so I stress the "in general" part.
Depending on the layout of your project, there may be some security concerns. For instance, if you have a .txt file with some sensitive information, keep in mind that it will accessible in your site.
Anything in App_Code or any .cs, .vb, .config, etc files will not be served by ASP.NET, so you can put stuff you don't want people seeing there.
Also, for initial loading performance, you should precompile your site via the VS Publish command or the Web Deployment Project addin (assuming you're working with a web site project). You could create an svn branch for the precompiled, deployable code and use that branch on your server.
You can use services like http://springloops.io or http://deployhq.com to only push certain folders to a server. That gives you a lot of flexibility in pushing code to deployment.
At my office, we have had a long-standing debate about Localization/Globalization and how to handle it. One side pushes for the Resource (.resx) file route built in to ASP.NET, one side pushes for a database driven solution. A third group believes in rolling a custom solution.
Of course, each method has its own unique benefits and disadvantages - and we've discussed it over and over, without ever coming to a real consensus.
So, I pose it to the community: in your experience, which method provides the best mix of the following as the application grows:
Maintainability
Extensibility
Performance / Scalability
In addition to just advice, we'd also be interested in any open source projects which might help to simplify the question, as well. Thanks!
Rick Strahl (An MS MVP) has a great tool kit for managing localization via the DB - offer the ability to update and modify on demand through a controlled environment and does much of the heavy lifting for you. Histoolkit offer the following features:
Data Driven Localization Resource Provider
Database driven Localization lets you store resources in a SQL Server database.
Interactive Web based Resource Adminstration provides a live Web based adminstration for that can edit and update resources while the app is running
Resource Editing Control associates icons with each localizable control and allows jumping directly to the administration form with the current resource id and locale selected.
Resx Import and Export lets you import existing Resx resources, interactively edit them with the data driven provider, then export them back out as Resx resources.
Localization Utilities like a JavaScript Resource Handler, functions to embed localized script values and much more.
He also summarises the issues very well here (Ive pasted some good bits here - not my own work!)
To Resx or not to Resx
The default resource storage mechanism in .NET
uses Resx based resources. Resx refers to the file extension of XML
files that serve as the raw input for resources that are native to
.NET. Although XML is the input storage format that you see in Visual
Studio and the .Resx files, the final resource format is a binary
format (.Resources) that gets compiled into .NET assemblies by the
compiler. These compiled resources can be stored either alongside with
code in binary assemblies or on their own in resource satellite
assemblies whose sole purpose is to provide resources. Typically in
.NET the Invariant culture resources are embedded into the base
assembly with any other cultures housed in satellite assemblies stored
in culture specific sub-directories.
If you’re using Visual Studio
the resource compilation process is pretty much automatic – when you
add a .Resx file to a project VS.NET automatically compiles the
resources and embeds them into assemblies and creates the satellite
assemblies along with the required directory structure for each of the
supported locales. ASP.NET 2.0 expands on this base process by further
automating the resource servicing model and automatically compiling
Resx resources that are found App_GlobalResources and
App_LocalResources and making them available to the application with a
Resource Provider that’s specific to ASP.NET. The resource provider
makes resource access easier and more consistent from within ASP.NET
apps.
The .NET framework itself uses .Resx resources to serve
localized content so it seems only natural that the tools the
framework provides make resource creation tools available to serve
this same model.
Resx works well enough, but it’s not very flexible
when it comes to actually editing resources. The tool support in
Visual Studio is really quite inadequate to support localization
because VS doesn’t provide an easy way to cross reference resources
across multiple locales. And although ASP.NET’s design editor can help
with generating resources initially for all controls on a page – via
the Generate Local Resources Tool – it only works with data in the
default Invariant Culture Resx file.
Resx Resources are also static
– they are after all compiled into an assembly. If you want to make
changes to resources you will need to recompile to see those changes.
ASP.NET 2.0 introduces Global and Local Resources which can be stored
on the server and can be updated dynamically – the ASP.NET compiler
can actually compile them at runtime. However, if you use a
precompiled Web deployment model the resources still end up being
static and cannot be changed at runtime. So once you’re done with
compilation the resources are fixed.
Changing resources at runtime
may not seem like a big deal, but it can be quite handy during the
resource localization process. Wouldn’t it be nice if you could edit
resources at runtime, make a change and then actually see that change
in the UI immediately?
Using Database Resources
This brings me to storing resources in a
database. Databases are by nature more dynamic and you can make
changes to data in a database without having to recompile an
application. In addition, database data is more easily shared among
multiple developers and localizers so it’s easier to make changes to
resources in a team environment.
When you think about resource
editing it’s basically a data entry task – you need to look up
individual resource values, see all the different language variations
and then add and edit the values for each of the different locales.
While all of this could be done with the XML in the Resx files
directly it’s actually much easier to build a front end to a database
than XML files scattered all over the place. A database also gives you
much more flexibility to display the resource data in different views
and makes it easy to do things like batch updates and renames of keys
and values.
The good news is that the resource schemes in .NET are
not fixed and you can extend them. .NET and ASP.NET 2.0 allow you
create custom resource managers (core .NET runtime) and resource
providers (ASP.NET 2.0) to serve resources from anywhere including out
of a database.
As you perhaps know, default method (which is actually industry best practice) for Localizing .Net Applications is using resource files (.resx in this case). If you want to use database, you would have to write your own ResourceManager.
From this, the answer should be obvious: use standard and do not reinvent the wheel.
You might be wondering why Localization via resource files became industry-wide standard. Well, there are many reasons (too many to mention here), most of them regard to Localization process. The key one is, it is painfully hard to update (i.e. fix or install) translations for database driven Localization. Just think of what you need to install it - some SQL script. You know what will happen if you send out this for translation? Or even mistakenly update it? These kind of files are not very safe to work with (and they tend to be very large), so either you would need to create some kind of generator (with resource-like file as an input, which totally bits the purpose...) or you would need to be very careful (and pray that a translator won't break the file).
That is to say, database-driven Localization is sometimes the only sensible way of doing things - this is when you need to implement so-called dynamic Localization, that is allow users to translate things or add their contents in multiple languages.
For static Localization (typical scenario) use resource files.
Localizing user interface should not be stored in database, it is preferable to use the standard resx method because this will give you the flexibility to customize the user interface of front end for each client/deployment, without the need to change the back end or store much data about each client customization in database.
Regarding data (bi-lingual data or multi-lingual data) store them in database and use whatever technique suitable for the context (table per language, or duplicate columns for each language).
using resx is the best approach for some static values that needs not to be manipulated via UI of the app but if your values needs to be updated DB driven would be the best for it. For me its still a case to case basis. But one of the blogs I have seen in the internet made the resx files updateable via user interface.. http://sandblogaspnet.blogspot.com/2009/11/updating-resource-file.html.. hope this would help you.
As all the above are true, I want to add some additional insights.
I tend to use .resx based localisation, when working on "static" projects/websites like Dashboards or other small websites, which are focused on a specific usergroup.
When working on larger and more "dynamic" projects like shops, service-offerings, etc. (esp. when content is localized - not only labels) I like to use database localisation.
When you are developing on larger projects each language is maintained by another person, who is not necessarily in your project (especially in community-projects). Thus maintenance of different languages becomes a real hassle.
On the other side providing users some good/easy UI to update their language is time-consuming as well. So try to find a good path for your project.
When developing for Alfresco, are there any advantages to using the MMT over Integrated Deployment? Is there anything you can develop using one method, but not the other?
Browsing through Alfresco's SDK examples, I noticed many of them used integrated deployment, and the same went for all of the Share webscripts I saw on Google Code. Right now I'm just using the Integrated Deployment method, and everything seems to be working well, but I'm curious if I'm missing out on anything by not using the MMT.
Modules and integrated deployments are exactly the same in terms of code capabilities. The main difference is about distributing your customization: if you need/want to
provide your customizations to the external world or
reusing them across different projects or
port them to different Alfresco versions
then modules are the way to go, especially if you're not releasing the source code. The only downside of AMPs is that they write something in the DB but you currently can't uninstall them, even if there are some tricks you can try out.
I personally still prefer using AMPs as much as I can for my customization, leaving to embedded changes only stuff that can't go into an AMP (e.g. overriding original Alfresco files). The maven way also helps (and drives you a little) towards this practice.
What is the simplest way to distribute an asp.net web application? I tried to look at some of the open source asp.net projects out there to see how they distribute their apps and how they do updates and they seem rather complicated to me (not for myself to perform but for non-technical users). A lot of them entail backing up the entire installed project, deleting specific folders and save parts of their web.config. I am hoping to find a solution that will make the update process specifically as simple as possible.
Thanks.
I am working on a project with a similar requirement now. We decided to use WiX to create an installer that can be run on the server or machine where the site is installed. WiX is incredibly powerful, but takes a bit to get the hang of.
There are plenty of other open source, and paid installer technologies as well. Here is a post with some info on a few.
CommunityServer provides a setup msi that will create a virutal directory, generate the SQL database and populate it with default data. Updating for point releases though is still a manual process involving an update.sql file and having everyone download then merge binary and static file changes.
They probably could have created an update msi too, but because so many people customize CommunityServer, it is probably better to let people merge changes themselves.
Do you mean in terms of breaking up the functionality into tiers that could be handled on separate machines, e.g. having 3 servers for a 3-tier architecture where one is the DB server, one handles middleware and the other handles the requests in ASP.Net? Another point here would be in going from a web server to multiple web servers in terms of scaling up.
Or are you referring to deployment?
It's a web application, man. Serve it publicly, require registration, and move on. Isn't that the point of the web application?
What are the suggested methods for using javascript files with MOSS 2007 ? in the 12 Hive somewhere or directly in the site's virtual directory in a scripts directory ? Or possibly as a embedded resource in a webpart ?
Personally, it all depends on what purpose the JavaScript files are going to serve. If they're going to be shared amongst multiple components then I would suggest placing them in the 12-hive. If however, they're going to be isolated to a single component - a web part for instance - then embedding them as a resource will work as well.
This article has a discussion about best practices for the deployment of web part resources which you may find useful, in concludes:
In this post, you have seen how to
both link to and embed Web Part
resources. Each has its own
advantages and disadvantages, mostly
boiling down to whether you need to
maintain the resource separately from
the Web Part. In both cases, the
resource file can be cached, so there
is little performance difference from
each option. Feel free to use one of
these two approaches for your next web
part.
I suggest you deploy these scripts in the 12-hive.
Having them in the 12-hive ensures fast access, which is important for scripts. You risk page rendering lag otherwise. More admin overhead as you must deploy them on all frontend webservers in your farm.
Having them in the content DB makes them more centrally manageble at the const of performance.
Mine where added to Sharepoint Designer in a folder I called "scripts" I think that puts it in the database.
We use a seperate scripts directory.
We use a similiar approach to images.
This allows us to share images and Javascript easily between our webparts, and custom applications which are available though Sharepoint.
This should also mean they're only downloaded once, and cached.