Okay, so ASP.net allows one to embed Images into an Assembly and access them using WebResource.axd.
I just wonder: What are the Pros/Cons of using Web Resources instead of Images in a folder on the Web Server, like how it's being traditionally done?
This article mainly mentions ease of deployment, but that doesn't seem to justify the extra amount of work.
One clear scenario is: third party controls.
I really don't want to deal with different script/image files for controls we are not developing. With embedded resources, its just the .dll file and that's it :).
The same applies if you are developing custom web controls that you will be using across different web sites.
I built custom controls that used by three different applications in same machine. When I maintain scripts for controls, I can forget deploying the new script file to every application.
In this scenario, it's good to embed resources into assembly and deploy assembly to GAC.
But the good point about external files (not embedding resources) is that, sometimes you realize a bug in script files. deploying it without resetting application is a good thing in an online application.
here is the rule i think it is the best,
if you have resources that wont change that often like, scripts, images. then you are better embed them in resources.
but if you have resources, that change versions like Jquery, then you should create properties to point to those external resources.
hope this helps
For me it is just a an another not-killer-feature added in ASP.NET . I do not think that it was implemented with serving a lot of content in mind but some times the added ease of deployment matters, then you gain some benefit. Question is when?
Microsoft states that they use it for eg. to serve forms validation scripts, and that due to caching it should not affect performance. That creates isolation for the controls and their scripts, so you do not have to worry about them yourself when adding them to your site.
So for me, if you think it helps you deploying user/server controls you can try. For serving images in general? I would not bother.
I would not put images into the assembly. It's just too much work for no apparent benefit. Is it faster? Probably not as Reflection-like speeds would be called in to get to the resource. Is it harder to maintain, you bet!
Why would a high-end developer be needed when the business wants to update a logo for example?
Related
We have a series of ASP.Net applications that have been written over the course of 8 years. Mostly in the first 3-4 years. They have been running quite well with little maintenance, but new functionality is being requested and we are running into IDE and platform issues. The apps were written in .Net 1.x and 2.x and run in separate spaces but are presented as a single suite of applications which use a common navigation toolbar (implemented as a user control). Every time we want to add something to a menu in the nav we have to modify it in all the apps which is a pain. Also, the various versions of Crystal reports and that we used tables to organize the visual elements and we end up with a mess, especially with all the multi-platform .Net versions running. We need to streamline the suite of apps and make it easier to add on new apps without a hassle. We also need to bring all these apps under one .Net platform and IDE.
In addition, there is a WordPress blog styled to match the style of the application suite "integrated" into the UI and a link to a MediaWiki Wiki application as well.
My current thinking is to use an open source content management system (CMS) like Joomla (PHP based unfortunately, but it works well) as the user interface framework for style templating and menu management. Joomla's article management would allow us to migrate the Wiki content into articles which could be published without interfering with the .Net apps. Then essentially use an IFrame within an "article" to "host" the .Net application, then...
Upgrade the .Net apps to VS2010, strip out all the common header/footer controls and migrate the styles to use the style sheets used in the CMS.
As I write this, I certainly realize this is a lot of work and there are optimization issues which this may cause as well as using IFrames seems a bit like cheating and I've read about issues with IFrames.
I know that we could use .Net application styling, but it seems like a lot more work (not sure really). Also, the use of a CMS to handle the blog and wiki also seems appealing, unless there is a .Net CMS out there that can handle all of these requirements.
Given this information, I am looking to know if I am totally going in the wrong direction? We tried to use open source and integrate it over time, but not this has become hard to maintain. Am I not aware of some technology out there that will meet our requirements? Did we do this right and should we just focus on getting the .Net streamlined? I understand that no matter what we do, it's going to be a lot of work. The communities considerable experience would be helpful. Thanks!!
PS - A complete rewrite is not an option.
Hmm, we're in the midst of a project to do something that sounds familiar. We're using www.sitecore.net CMS but you could use the Open Source alternative Umbraco again both of these will have a learning curve, but they're .Net apps and aren't targetted specifically at blogs. SiteCore ultimately can use normal .Net user controls if you want, though it's slightly against their model, but it works.
One thing I'll warn you of is SiteCore Must be the root of your website, it has to control the root of the domain (it has a urlrewriting module that needs to be at the root) and you can tell it to exclude certain folders where your applications might live. You can obviously put your navigation in a folder under the root of the site. Also note SiteCore's a .Net 3.5 application running under the 2.0 runtime.
Are your sub-applications.. Actual seperate applications in virtual dirs or something I'm guessing?
Depending on the nature of the .Net apps, you may find DotNetNuke to be a useful choice.
It's a CMS where you write widgets ('modules') in .Net, then add them to the pages of the CMS. In your case, you'd wrap your existing functionality in such widgets. I've done exactly this several times, and now that I'm used to it it's no big deal.
The downside is you have to learn to swim in the DNN environment, which (like any CMS) has a bit of a learning curve.
I'd have to know a lot more about your existing apps to be sure this is a plausible option. If it looks appealing, you should probably contact someone who's dealt with a situation like yours (such as myself) and go into detail. It's very easy to find yourself in a dead end with these CMS frameworks.
Edit: Like a product mentioned in a different answer, DNN has to control the top level of its subdomain -- all requests begin by going through Default.aspx and are then dispatched in various ways.
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.
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.
Obviously having whitespace in css, aspx and html pages is a great advantage at design time. But is there a way to (a tool that will) clear all the whitespace from all the files and possibly merge javascript and css files in a more optimal way.
I am using asp.net themes so there are quite a lot of separate css files that would be improved through some form of automated combining. I have seen a few http modules but that isn't quite what I want I just want to run something over the published project beofre sending it to the server.
EDIT: Compression at least in IIS is unfortunately not an option, we are currently running it on the same IIS server as a third party web based student management system. It doesn't like compression and the IIS options don't seem to be per application pool. I did apply asp.net compression but the bulk of my extra data seems to be the app_themes which I know would compress well I just don't want to have to manually go through compressing all the css separately.
An empirical study on the effect of removing white space from a not-untypical website (Drupal) showed minimal effects. (site also contains some links to non .net html white space removal tools)
I have gotten magical improvements in page size by aggressively managing viewstate size and using Blowery's http compression module.
Another strategy is to do minifiation (merging many css files into one). Telerik has such a component RadStyleSheetManager, it works only with style sheets embedded into assemblies.
There is another way
http://omari-o.blogspot.com/2009/09/aspnet-white-space-cleaning-with-no.html
I think one of the reasons that this was never included in .NET was because they expected you to turn on server compression in these scenarios. IMO I don't agree with this -- I think it's a shame that at least aspnet_compiler.exe can't do this optimization. It would be such a great performance boost on uncompressed connections. Anyway, you can enable compression on IIS 6:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true
And it's even easier and more flexible in IIS7 to do so. I hope someone has a better solution than I!
4 guys from Rolla just published an article on a http module that removes white space. You would need IIS 7 in integrated mode to make it work for css (or possibly IIS6 with wildcard mappings)
It looks more like a proof of concept, but the code is free.
i found this:
http://msdn.microsoft.com/en-us/library/aa719805(VS.71).aspx
greets!
Scenario:
Let's say I have four very similar applications (i.e. most of the functionality is the same, but they are different enough to justify each being seperate applications).
What is the best way to re-use the common functionality code between them? COM+? Web services?
In general I'd typically just have the code in a seperate project (dll), but anytime that's updated, the file has to be updated for each ASP.Net application, and wasn't sure if there was a better way of going about it.
Thanks!
If possible, you can create a Visual Studio solution with a DLL Project and a number of Web Application or Website projects. The web projects would have a "project" type reference to the DLL project, and everything would build at the same time. Then you could use the "Publish" tool for each of your web projects as needed.
If all the apps are on the same virtual server, consider placing the shared assembly in the GAC. This allows you to diverge versions should the need arise, and keeps everything in the same place as a bonus. Downsides: this assembly runs with full trust and you should use policy and CAS to ensure there are no elevation of trust leverage points for external untrusted assemblies. You'll also need to learn about the [AllowPartiallyTrustedCallers] attribute.
As for the other choices, COM+, meh, a bit heavyweight. Good for transactional stuff. Web services, not so good for data heavy services, but if done right, can be fairly maintainable. The more it's shared, the better the pay off.
You can have your project, but instead of adding the common dll to the project reference add the common project to all solutions and then add a reference to the common project.
This way you can have one project on any number of solutions and you have your problem solved ;)