I have created a new ASP.NET 4.5.1 web forms project.
I have used bundling & minification in MVC 4 previously.
Why is there a bundle.config file in the root - and a BundleConfig.cs file in App_Start - that both appear to list files to be bundled?
What is each for and why do they appear to do the same thing?
This question was asked here but not really answered (even though it is marked as such):
Bundling resources via bundle.config vs BundleConfig.cs in ASP.NET 4.5 WebForms
A lot of it comes down to whether you prefer working in code or in markup, but each does have some pros that are specific to that method.
For the bundle.config, there's really only a single benefit, but it is a big one. By using it, you can manage bundles without having to touch code at all. This means that you can make changes without recompiling, making quick deployments easier. Also, it means that your front-end developer, who is going to be most familiar with the files that should be bundled, can define the bundles without having to work with any back-end code.
However, there are quite a few limitations on what you can specify in the Bundle.config. For instance, you can't specify any custom transformations to be applied to individual items or bundles. The only bundle properties that you're able to set are the Path, CdnPath, and CdnFallbackExpression. You can't set the Orderer or EnableFileExtensionReplacements properties. You don't have a way to include a directory including all subdirectories (like you can with the IncludeDirectory method). Basically, there's a LOT of functionality that is only available through the back-end code. Granted, a lot of this you could set by using back-end code to retrieve a bundle that was defined in the bundle.config, and then manipulating. But if you're going to do that, you might as well create the bundle in the back-end, also.
My personal philosophy is to use Bundle.config unless I need to do something with the bundle that's not possible that way. However I'm sure some completely reasonable people would disagree with that.
As far as the default VS template for Web Forms projects having both, I'm guessing it's just to demonstrate that both options are available, since it's not doing anything in BundleConfig.cs that couldn't also be done in Bundle.config.
Related
I have an ASP.NET MVC project that is deployed via Visual Studio's Web Deployment - all works fine so far.
I now need to deploy another version of the same project (e.g. for a different customer) - with the same code base/functionality, but with a different layout, i.e. other CSS and images (maybe even with different views/Razor code). Ideally, the content from the other configuration would not be published at all.
I know I can use different connection strings for the persistence layer - but is there a way to configure also configure other content elements?
I'd like to avoid having two versions (or later even more) that required branching/merging - but rather like to simply deploy the latest version with the different "themes"...
I have a MVC project with 4 class libraries. And i deployed it into 3 other domains.
I copied only MVC project without controllers or code classes for each client, and added them into my solution. I use them only for visual changes or themes. Not for server side functionality. So the copied projects' assemblies shouldn't be deployed. Only the UI files should be deployed. Assemblies are deployed from the original MVC project's output folder.
I build solution and publish dll's into 3 domain, and publish only each client's UI files into it's server.
This enables me to develop server-side functionality in only one MVC project. Separate UI files from server side functionality.
Hope this helps.
are you using MVC then?
What you can do is to override the default razor engine and create your own. What the razor engine does is mainly to map your requests to views in particular folders, you can tell the razor engine when to map those requests to views in one folder or another.
MVC4 Razor Custom View Locator
A full fledged explaination is here :
http://nickberardi.com/creating-your-first-mvc-viewengine/
That is for views, if you just want the CSS or JS to be different, you just have to map your requests to a razor bundle and then vary what the content of the bundle is depending on a variable, or the pressence of a configuration file, or by filling a variable with a value from the database.
As you can see here bundling is very easy :
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
Say your html points to : /assets/mycssbundle.css , but what that file would actually contain can be altered by where you tell to the bundling function that the files are located.
This seems like a design question. If you foresee possible changes like this in the future, and you already swap content via DB, then you should consider loading css file from database. There're of course many other ways to do this but simple and efficient is preferable.
This would mean structuring your html properly to ensure all layout is properly handled via CSS and can be achieved via ViewData or ViewBag. See case example.
Edit:
Not css data but the relevant css file.
You have two options:
A) Develop a custom view engine that switches between different page sets depending on the configuration. This will allow you to switch between the page sets just by changing the web.config settings, which fits well with the visual studio's built in deployment model (different web.config transformations kick-in for different deployment environments). One implementation that comes to mind - switch between view engines for different deployment environments (in different web.config transformations).
Unlike the other suggestion to load pages from the DB, I would recommend loading them from folder or physical location (e.g. different view engines targeting different sub-folders of the project). DB approach is not developer friendly when it comes to developing and fixing pages and their markups that are in the DB.
B) Develop all page sets (all variations) under the same project and then write custom deployment scripts which deploy particular page sets depending on the deployment environment. Drawback of this approach is that it's hard to notice issues like page sets intersecting or links crossing the page set boundaries.
While plan B sounds a little bit simpler development-wise, it can become a nightmare maintenance- and deployment-wise.
So, I recommend plan A.
Your Question is too broad.
However we have also a similar use case. We put all the theme related stuff (css, images, etc) as an embedded ressource in a separate assembly. We have Customer1.Theme.dll and Customer2.Theme.dll etc.
The App loads dynamically the Theme.dll and references the ressrouces from there.
Among other solutions,
assuming that you are using asp.net mvc.
and assuming that you have content1 and content2 folder available in the same repository or making available in same repository is not a concern.
and assuming your are bundling your contents.
and assuming your images are referenced only using css.
You can have a app config key which will tell you whether you want content1 or content2.
something like,
<add key="sitecontent" value="content1"/>
Now in your Application start in global asax, read the app config key and depending on the value, call the
BundleConfig.RegisterContent1Bundles(BundleTable.Bundles);
BundleConfig.RegisterContent2Bundles(BundleTable.Bundles);
I think this is a design issue. As you can see below you can organize your .net application in different layers:
Source: Microsoft
There are some key principles (Separation of concerns, DRY, etc) that Microsoft strongly encourages through the .net platform and I believe will find good use in your project.
Based on what you describe a simple approach is to keep in one project -same for all clients- your business layer (including the Services or the Data layer - even with different connection strings for each project) and create separate projects for the Presentation layer.
You may find more information from Scott, CodeProject, or more traditional methods (BTW this is a great book).
In a website, I see some developers put code into app_code, and sometimes appcode (due to some bug), other files into DataModel, and other files into miscellaneous folders.
Is there a standard approach to organizing code within an application?
How is it different between an ASP.NET, MVC, Silverlight, Console, Database, and WCF application? The reason I mention WCF is because many people seem to have a shared types library that is linked between the server and client code.
Where can I learn these common practices without having to try, fail, and try again. I'd rather just learn it once from the experts.
the most standard well organized is MVC framework. For anything else, mostly i organize folders as namespace.
eg companyName.projectName.folderName
myCompany.StackOverFlow.Extension
myCompany.StackOverFlow.OpenID
There is no set in stone 'best practice' standard for organizing namespaces. My personal approach to keeping projects organized is to limit the content of any directory/namespace to about 20 items. This means I can fit the full contents of a folder into my screen, and also see every other item surrounding it (assuming other folders are collapsed).
On the other hand, lots of folders without much content can make navigation difficult as well.
Another thing you should do is to separate your solution into projects based on dependencies. For example if you are using m-v-vm, you should have a project for each of Model, View, and ViewModel.
Files placed in AppCode should only be files directly relevant to the presentation modules. Other files (ie ViewModel, Model, Controller etc depending on the framework you're using) would be preferably placed in separate projects.
Take a look at the "WCF the Manual Way…the Right Way" http://www.code-magazine.com/Article.aspx?quickid=0809101
We have two asp.net sites (based on episerver).
Using Telerik Asp.net controls.
We have some functionality that we want to have available in both sites.
Right now one of the sites use webparts/usercontrols and the other uses usercontrols.
Is there any way to share the functionality between these sites?
What I would like is to be able to share usercontrols between the sites.
Since your talking about user controls I'm assuming you also have .ascx files that are part of the user controls, which makes this tricky.
I guess the ideal solution would be to move everything into server controls, that way you could just reference the assembly, but if you are inheriting from other controls that utilize .ascx files, your kinda stuck with them.
One way of handling it is to use the file linking capabilities in Visual Studio (Add Existing File, click the down arrow, choose link option) to share the same physical file between projects within the same solution. This is not ideal simply because you have to make sure that the ascx files are copied to both sites prior to deployment (I've done it with a post-build script before), but there is a lot that can still be pretty fragile.
Another option that is more technically complex, but probably a "better" way of handling it would be to use a Virtual Path Provider to do the work for you. Here is an article which talks about using Virtual Path Providers to do the sort of thing you are wanting to do.
Start a new class library project, reference that project in both your site projects, then pull out the common controls and code into the library project.
Like mentioned you could put the files in a VPP directory in the live environment and that way only have to copy ASCX-files to one folder for a two-site-code-infront-update. Code-behind updates would need the DLL built and overwritten for both sites though.
If you are using SVN in your development environment you could also setup a svn:external linked folder from one of the projects and that way only have the code and it's revision history in one repository.
One of the projects I was in charge of as a JSP/Struts developer at my last employer was a themes tag library (present on every WebSphere server as a shared library) that let any Java web dev in the company pull in any of the standard themes like intranet, public, etc. with minimal effort. The themes included header, footer, navigation, and links to css & javascript, etc. They could even customize things a bit when we gave them the option, like choosing a selected tab.
This setup was ideal because we could make centralized change to any standard UI elements and they were automatically pulled in by all sites using themes without any effort by the site developer.
With the new job I started in December, I've switched to using ASP.NET. I'd like to propose something similar in spirit to the themes app here, since we're running a bunch of different sites that should have a unified look and feel.
What's the best way to accomplish this? I'd rather not have to recompile anything to update the theme to make this work.
Edit:
Although I was hoping for a better answer, the .NET gods apparently don't approve of what I was trying to accomplish. Here are the three options that were found:
Compile a Master Page into a DLL and put it into the GAC:
This works in simple cases, but as a hack it's too brittle. I couldn't get it to work correctly with our site.
Create a virtual directory to the Master Page in each web app: This actually does work, although it doesn't make for a very comfortable development environment. However, one of the things we are trying to move away from is having to create virtual directories inside each web application. No dice.
Create a bunch of custom controls, compile them into a DLL, and put it into the GAC: This is the answer I selected. It's the least centralized option and requires more work for the developer of each site, but it seems to be the only Microsoft-blessed way.
In conclusion, I'm pretty frustrated with .NET over this. In the grand scheme of things Master pages are just code, and I don't see any reason why they couldn't be easily centralized for use in multiple web applications. This seems to be a major loss compared to JSP/Java.
You can put some UI into the form of custom controls or server controls (if not in MVC) and then place them in the GAC thereby distributing them. All references to the controls in that assembly will be pulled from the latest version in the gac. You can also do things via the Machine.config which is controlled at the server level rather than the app level.
Currently I am developing a site with about seven partial classes, a few icons, three pages and an App_Themes folder. I was interested to know, is there an industry standard directory structure for anything larger than a small project?
For example, I want to keep the classes in separate folders, the images in separate folders etc. My current directory structure is as follows (not exact, this is from memory):
(root) contains the codebehind and forms
/App_Data
/App_Themes
/Bin
/Images
/Models - I stole the name from MVC. It sounded more appropriate then 'classes'
/FusionCharts - a flash charting library
I briefly played with MVC, and it looked like a nice directory structure, however, I am using ASP.NET Ajax.
So, I guess the question is, is there a way to make this directory structure more orderly in your own opinion? Please give answers as to why you made your decision also :).
I like to be inspired by Microsoft standards, since we are using a Microsoft technology. Plus a somewhat good standard is better than no standard, especially if you work in a larger team.
App_Code is standard of course, because it has a function in ASP.NET, not just a best practice.
I sort of like the MVC standard project's structure:
Content -- Contains subdirectories with Images, Css, Javascript
Controllers -- Maybe N/A in WebForms
Views -- Also maybe overkill in WebForms
The "Content" folder is maybe the key, since it's the lowest common denominator for ASP.NET projects. So if you work with both WebForms and MVC you'll feel at home in all projects, if you know you have your static resources in that folder.
The only "standard" name you are missing for ASP.NET would be App_Code.
Use the convention that makes sense to you and the people that will be maintaining the code. There is no industry standard for this that I've come across in 4+ years of doing ASP.NET development.
I also follow the same structure as mentioned by you. The only additions that I make is have separate folders for scripts,CSS, and resources. As far as I am aware of there is no such industry standard.
I like having a Content folder under which I can put my Css, Js, and Images folders.
Many ASP.Net Web Forms projects will also have a Controls folder for the ASCX controls.
For css styling, we generally use a styles folder, images for image content (sorta an obvious one), js.
You might have a schemas folder, App_Code for ASHX handlers and other types of application code, and a MasterPages folder.
Some auto-created you might see in a Web Forms project are folders are Properties, App_Data, bin, obj, Packages, and TestResults.