Recently I've made changes to an application which had 20 different .js files being referenced, to using bundling to bring this down to one file.
This includes:
Frameworks (jQuery library)
Custom logic (global logic for header navigation etc)
However after deployment this showed that we we're no longer making use of asynchronous downloading of javascript files.
Therefore our waterfall effect was replaced by one long download.
Has anyone ran into this problem before? Are there any guidelines for bundling which suggest multiple over single?
It depends on your application. Unless its a single page application I will prefer to separate the files into multiple js files based on functionality. If you have multi-page application instead of forcing client to download bulky large one file, separate them based on usage. Club together only those which are used by most of pages otherwise keep them separate based on functionality.
Related
Can I use a styles.css file uploaded on GitHub as styles for multiple projects? I'm trying to define a default style for my projects here: https://raw.githubusercontent.com/GhitaB/default-design/master/styles.css
I prefer to link this file instead of copying it in multiple projects.
RawGit serves raw files directly from GitHub with proper Content-Type headers.
Or, consider using Github Pages
Here we need to distinguish between duplication of code and resources. What you don't want is copying code, because those files would diverge and you'd need to repeat every change for all of them. Having one file uploaded to multiple servers, however, shouldn't be a problem as long as you have one place to edit them all at once.
For this case there's Git submodules. The idea is basically having a repository with the shared part and then including that repository in a specified path in your other projects. You can read more about it here: https://git-scm.com/book/en/v2/Git-Tools-Submodules
This way all your IDE-based and external tools will still work and your website can be deployed as a whole. If, at some point in the future, you decide to have separate CSS files, you can simply replace the submodule with a file and you won't need to change the paths in HTML.
Of course, you can also use the same exact resource in multiple projects simply by pointing them to the same URI, but then the uncoupling might be harder afterwards and you can't see the file in your IDE.
We have a lot of websites with common functionality developed by 3 persons, in the business logic we use a common library project (in a shared directory) so we all use the same functions. This way the corrections and improvements are shared for the following projects or when we recompile an existing project. We have a class for some UI common functions too (loading a ListControl with x data and so)
The problem is with some web parts like CSS, Javascripts, Common Pages (login, configuration, customer management), those we don't know exactly how we can centralize them so we have those parts in the shared project so we don't have to copy paste corrections/improvements manually to the other websites each time...
Example of current website structure:
-MyWebSite1
-Styles.css
-Scripts.js
-Login.aspx
-Funx.cs (Functions specific to this site)
-Consx.cs (Session and other variables specific to this site)
-CommonProject (In a network shared directory)
-FunBusiness.cs
-FunWebUI.cs
-ConsBusiness.cs
-ConsWEB.cs
Is there a way of doing this?
For now the closest we have come to solving this problem is following this article for the Javascript part:
http://msdn.microsoft.com/en-us/library/bb398930(v=vs.100).aspx
We are now investigating using only one reference to a js file and including the other javascript references dinamically and the common CSS and MasterPages parts...
Maybe you can add those common references files as Linked File in Visual Studio. In this way you can maintain one file, while kept in a different location.
From Microsoft:
Link file leaves the file in its current location and maintains a link to the file from your current project.
Another solution would be to create a copy script before compile in Visual Studio. Reference over here.
I have a big ASP.NET application (legacy) which actually (functionally) is composed from two portals. So I need to split it to two separate applications, to ease the development on each of them.
Of course there are shared features between the two. Some of them are in DAL and BL, and that is not an issue - all that code was separate din separate projects, which made up assemblies that are to be referenced in both apps.
But the problem is with some pages, lot of user controls, some css and javascript files, which are shared between the two "portals" (applications).
I'd like to ask for some advice on how to handle them. My main concern is to avoid duplication, so ideally they should stay in a single place, and be used by both apps.
First I tried was to add files from one project to the other as linked files. While this works for code file (they get built into the project they are linked to), it doesn't for aspx / ascx or css / javascript / images. It does if I publish first (if marked as content, they get copied during publish), but I can't do this all the time during development, and such files are not found when app is debugged / run from source code (sincve, obvious the linked files are not actually available in app file tree, when one is looking for any of them.
Another thought was to create pre-build event, and in that to copy all shared files from a common location.
e.g. I create a project Common and put there all files that are shared between applications, organized on folders, and on pre-build I perform an xcopy.
And another thoughts is to make all shared files part of a SVN repository which I reference with svn:external, in both projects.
But all looks to my little cumbersome. Does anyone had similar situation? How did you handled it?
Any advice on any of my suggestions?
You have, at least, two options :
sharing through virtual directories : https://stackoverflow.com/a/13724316/1236044
create user control libraries : https://stackoverflow.com/a/640526/1236044
The virtual directories approach seems straightforward for ressources like css, js, images.
I also tend to like it for sharing user controls.
The library approach should need more work, but would ensure better reusability of the controls on the long run.
I had an identical problem this week with css and javascript files triplicated across three legacy projects.
I removed the files from two of the projects and replaced them with linked files to the first project, but when I ran the website I got 404 errors for css & javascript files missing in the pages belonging to the two projects.
So I simply added the nuget package 'MSBuild.WebApplication.CopyContentLinkedFiles' to my solution and everything worked fine - the css and javascript files were deployed fine for the two projects and my 404 errors disappeared.
I didn't have any shared .aspx / .ascx files, but I would imagine it will work for them too.
See also this question / answer.
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.
I have a web application that is becoming rather large. I want to separate it into smaller more logical projects, but the smaller projects are still going to need to access some of the classes in the app_code of the main project. What are some good methods to accomplish this?
Add a class library project with the common classes and add a reference to this project to each of the new projects.
So you'll have the following Solution layout
/webapp1
/default.aspx
/....
/webapp2
/default.aspx
/....
/lib
/Utils.cs
If you are only looking for a way to organize your files, then you can create a folder for each sub-project. This way you'll be able to get to the content of app_code and maintain a level of separation with very little rework.
If you are looking for the best way to do this, then refactoring your code to have a common Class Library based on what is reusable in the app_code folder and multiple, separate projects that reference that library is the way to go.
You may run into problem refactoring the code this way, including not being able to reference profile or user information directly. You are now going from the Web Site to Web Application paradigm.
http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx
Extract your common code from app_code into a class library which is referenced by each of your other projects.
I like the 3 Tier approach of creating a data access project, a separate business project, then use your existing site code as the presentation layer, all within the same solution file.
You do this, like posters before me said, by creating Class Library projects within your existing solution and moving your App_Code classes to the appropriate layer and then referencing the data access project in the business project, and the business project in the web project.
It will take a bit of time to move it all around and get the bits and pieces reconnected once you move so make sure you set aside plenty of time for testing and refactoring.
In CVS & Subversion, you can setup what I think are referred to as "aliases" (or maybe it's "modules"). Anyway, you can use them to checkout part(s) of your source control tree. For example, you could create an alias called "views" that checks out all your HTML, javascript, and css, but none of your php/java/.NET.
Here's an example of what I'm doing within my projects.
The basic idea is to have all common files separately from htdocs so they are not accessible by client directly and sharable.
Directory structure:
public_html
The only htdocs dir for all projects.
Stores only files which should be directly accessible by client, ie js, css, images, index script
core
Core classes/functions required by application and other scripts. Framework in other words.
application
Stores files used to generate separate pages requested by public_html/index script + classes common to all projects
config
Configuration for all projects, separated by project
templates
Template files separated from all other files
The public_html/index script is then used for all projects on all domains/subdomains and based on the requested URL loads proper pages...
A somewhat simple approach is to group the code in your app_code folder into it's own assembly. The only issue that you could possibly run into is if the code in your app_code folder is not decoupled from the elements on you pages (This is normally always a bad idea since it indicates poor cohesion in you classes).
Once you have your code in a separate assembly you can deploy it to any number of servers when you are upgrading you apps.