I'm inheriting a web application and the previous programmer compiled all his code into a .dll. The .cs files are not present on the server.
Working on previous projects, I've always uploaded the .aspx file and the corresponding .cs file. It's never been a problem for me and I always thought it was standard procedure. Am I wrong or just paranoid?
Will,I think this is quite common to keep code precompiled into dll. Then the code is less exposed for potential security holes. This provides also many advantages, which include faster initial response time, error checking, source-code protection, and efficient deployment. This is particularly important in large sites where there are frequent changes in Web pages and code files.
Leaving source code as a part of the project isn't necessarily the best source code management process. There are tools for that.
Also, precompiling source code isn't out of the ordinary (this is a Web Application project rather than a Web Site project in Visual Studio), and has many benefits.
Note that this doesn't make you wrong or paranoid.
There are good reasons for both strategies you just have to figure out what is going to work best for you environment and for the application.
In some ways it is good to have it precompiled if you worry about someone accidently making a change on the server but not checking the change into source control. With non-precompiled if you don't have change control on your server it can be hard to figure out who "accidently" made a change and why without checking it in.
On the other side, if you don't precompile it can make deployment more straight forward.
Just do a little research behind both strategies and decide what is going to work best in your situation.
As Nader pointed out, in a Web Application you don't need the CS files at all. There is not a huge risk of the source files being served accidentally, as protecting these files is a core function of IIS request management. Still, it is generally good practice not to deploy them to a production web server.
In any case, source files should at the bare minimum always be backed up in a location that is not the web server and should be source controlled whenever possible. I have seen too many websites where the source files were lost and the site was useless as a result.
Like everyone above has said, compiling source code into DLLs is considered best practice.
If you'd like to see the code of the DLLs you've been left with, there's a handy (and free!) tool called Reflector (apologies if you've already got it)
http://www.red-gate.com/products/reflector/
Just load up the DLL and then disassemble to view the source.
Web Application Projects compile into .dlls and leave no source on the server.
Web Site Projects deploy all the source to the server.
It's a religious war as to which is best. Google will present you with many varied opinions, so I won't press my own opinions on you.
Related
I'm working on a sub-application for a large system.
There is a company X which has created the system. Sub-applications are created by numerous smaller companies, including the one I work for.
Our application is close to being finished but there is a new requirement that our application must not use DLL files and all the business logic should be contained in .cs files.
Why is there such a requirement? Company X believes it can solve the problem of having too many DLLs and dependency issues. With many sub-applications and many different companies creating them, problems arose with /bin directory and dependency issues.
Main problem is that many sub-applications are interlinked. Service Oriented Architecture is used.
I understand this is an architecture problem. And requirement also came way too late.
I'm a developer.
More specifically about my problem:
It's simple when it comes to ascx.cs files, I can just switch from CodeBehind to CodeFile. No problem here.
Problem is with our libraries. Obviously, I can just copy all the corresponding .cs files on the server but how do I make the application load the classes from there instead of using DLL libraries?
I have never implemented an asp.net website without using DLLs, it is not clear to me what are my options.
I have been reading about:
How to load a class from a .cs file
I hope I've explained my situation well enough.
Company X no doubt has someone leading the developers who once had a dependency issue. They have now decided that any and all dependencies that are in the form of an actual assembly are bad (I think we've all had a manager like this at some point).
The fact is: this isn't possible. It is a stupid requirement that makes your life much, much more difficult.
You have two options that I can see.
1) Remove all of your (hopefully) nicely decoupled assemblies with their nice business logic out into your code behind files. This is tragic.. but an option.
2) Continue down your path of investigating compiling code from a source file. This sets you up for a HUGE amount of extra development time and.. honestly, you'll probably just end up giving up.
Save yourself some hassle and just offer them your full source code on USB.
Sorry if that sounds harsh. I do not envy you though.
Offer to license your source code to them but at much higher price than the binaries. Source code has much more intrinsic value, because it is your intellectual property.
Also beware that company X can decompile your binaries into source code using e.g., ILSpy. How much do you trust them not to do this?
Scenario: I have access to an already published ASP.NET application running on a remote web server. The directory structure looks like this:
I do not have access to the project/solution files as far as I know. Specifically, I cannot find specific C# code-behind files that I need to modify.
Is it possible to rebuild this project with minimal effort using only the published code?
A couple of clarifications:
To refactor something is to alter its internal structure without changing its external behavior. You can access source code by using a decompiler, but it is often not worth investing a lot of time into because the decompiler has made formatting decisions that make most code difficult to read for humans (as it was already stripped down for machine only readability).
Refactoring is usually only done to either improve the performance or readability of the code, so you are starting at a loss if your goal is the latter. My guess is you need to go in and tweak some functionality, in which case a decompiler is really the only way to go, but finding the source code and keeping good track of source code is probably a better bet. When we deploy code to production we include a ReadMe.txt file with it indicating where to look for the source code.
Additionally, some asp.net files are not compiled into .dll's. Typically .dlls only include files ending in .vb or .cs. You'll still need to have access to and include non-compiled pages like .aspx and .ascx files, but these will also be on your server.
A good free alternative to .NET Reflector is to use Telerik's Just Decompile which has an option to recreate the .proj file from the compiled code.
You could use a de-compiler like .NET Reflector to decompile the dll's but that will only work if the code hasnt been obfuscated. Even then you might not be able to regenerate all of the files from the original solution.
I am looking for the best solution to make it easy to add new languages to an asp.net website without deploying/building the existing code base.
From what I have researched, it seems that you can compile resource files on the fly into Satellite assemblies but I am uncertain how to make the application use these DLL's once generated?
The other option I have seen is to store the translations in the Database, and write a custom ResourceProvider so that the built-in localization methods can be used, whilst abstracting the actual implementation (in this case a database).
Either way, the front end for this site will be the same (meta:resourcekey for the controls etc).
But I am struggling on deciding which approach will be the easiest to upkeep. For example, does publishing a new Satellite Assembly restart the Application Pool or does everything tick over nicely?
EDIT
The translations will be provided by a 3rd party API so human maintenance quality is not important. I thought I would add this due to the answers received.
With Asp.Net (currently) you do not have to compile by your own, you can simply deploy resx files (to App_LocalResources or App_GlobalResources folder) and Asp.Net will take care of compiling them into Satellite Assemblies. That's cool.
With Database approach, you are risking the problems with synchronization: how will you know if given resource string is translated? Also, correcting them is not very easy (for Translators/Localization Engineers). And you would need to prepare "install" script anyway. If that is what you are going to give to translators, good luck. You would face plenty of overtranslations and you would have to correct them (manually?).
Resx files (being simple XML) are a bit easier to validate (it is either valid XML in terms of given XSD or it is not). Besides, it is standard technology, you won't need to implement anything by yourself. That is why, I would recommend it.
EDIT
Another issue with Database-driven resources could be character encoding. You would need to create your own translation kit. My experience is, the result might be in several different encodings. Especially, if you want to use plain text file. On the other hand, default encoding of XML files is UTF-8...
RESX
Having around 30+ languages in mit Windows Forms and Web Forms application (this one, if I'm allowed to place a link), I finally had most success with simple RESX files in App_LocalResources.
What I discovered though was that the compilation was extremly slow in VS.NET, so did a slightly modified approach:
Have only English RESX files in the VS.NET solution.
Have a shadow structure of the website with only the App_LocalResources for all languages, including English in a separate folder, not visible to VS.NET.
Write a simple CMD script to copy the real English resources to the separate folder.
Use my free tool Zeta Resource Editor to actually translate inside the separate folder.
Have a publish script that copies the real web files (like ASPX, ASAX, MASTER, etc.) to the website and also copy the resources to the websites.
This approach makes compilation really fast and still allows me to keep compilation and translations separated.
The drawback is that the first call of the live web application compiles rather long, until now, I figures no way to speed this up/precompile (although I do believe that this is possible).
Database
I also did some projects with localization in database and custom <%#...%> blocks to load the languages.
Today, I would vote against this as it is non-standard. Although it would be probably just as fast to compile, no matter whether 1 or 50 languages are involved.
3rd Party Tools
You also could fetch a commercial product to do the translation, if I could afford, I would have done this most likely, too.
Just my two cent...
How do you precompile WCF code so that the WCF code can't be seen by anyone who has access to the WCF code.
it's possible to this with ASP.NET code by using the "precompilation" feature. basically, what the precompilation feature does is enable the developper to deploy "binaries" to IIS instead of a folder containing source code.
can this be done with WCF too ?
I think you may be confused about something.
A WCF project is always "pre-compiled", unless you go out of your way to be unusual. The source files do not need to be deployed in order for the service to operate.
What leads you to believe that your source code needs to be deployed?
You're looking for an obfuscator.
I'm not sure why people are DVing your post as this is a legitimate question. However what you are actually looking for is source code protection not pre-compilation.
Source code protection can be many faceted to be effective however I routinely state it's generally worthless as you will spend alot of time and money for a very intangible benefit. If your product is based on a brand new algorithm that has true commercial value C# is definitely not the optimal language to develop that module in.
There are posts on here about this topic: https://stackoverflow.com/questions/402430/how-do-i-use-net-without-loss-of-control-over-intellectual-property being on of them. It's also possible this question will be closed as a duplicate.
We’re coming to a big release in a web project I work on, and I’m starting to think more and more about javascript/css performance and versioning. I’ve got a couple high level ideas so far:
Write (or customize) an http handler to do this for me. This would obviously have to handle caching as well to justify the on the fly IO that would occur.
Add these steps into a custom msbuild script that would be ran for deployment only.
I’m also looking at automatically generating config files for each of the servers I deploy to, which lends itself to the second idea. The major advantage I see with the first idea is that I could dynamically handle versioning (at least that’s what one of my links at the bottom says, I’ve yet to convince myself that this would actually work).
Anyway, I’m curious if any of these problems have already been solved. I’d love any feedback. Thanks!
Here are some resources that I've been looking at so far:
http://madskristensen.net/post/Combine-multiple-stylesheets-at-runtime.aspx
http://madskristensen.net/post/Remove-whitespace-from-stylesheets-and-JavaScript-files.aspx
http://www.west-wind.com/WebLog/posts/413878.aspx
http://svn.offwhite.net/trac/SmallSharpTools.Packer/wiki
You do this as part of the continuous integration build process you have.
Compare all JS to the previous checked inversion, for each that have changes, call out to the YUI Compressor on that JS file and name the output with the current revision number. Add that file to your repository, and change a config file to have the latest revision number for that js file. Then you will write a custom control that imports a js file. This control will either use the uncompressed js when running on a development machine, or the compressed file with the revision number from the config file when it is run on a deployed setup.
In addition for 1), Microsoft has built in support for embedding resource files into DLL. This will always get updated when your project is changed and recompiled.
The problem is, you don't have control over caching and file name. When debugging, it's hard to pick which one to debug when everything is called "webresource.axd" something. That was hell.
Would love to read how others do it, too.
Personally, I rather have it done as part of the build process as to avoid the performance cost of dynamically doing this on each request. I guess you can lessen the hit by implementing proper caching, but why bother... IIS can handle that for you already (unless you are not running on top of IIS, I guess).
As a general recommendation, things that Steven Souders talk about is also great if you want to speed up browser rendering. If you have not already, take a look at this.
My team recently moved away from keeping scripts as embedded resources and we are very happy with the results. Yes, you can combine and minify them using handlers, but it's a bit of a hassle, especially when you want to host them from a separate domain.
What we do now is we keep all of our control script files separated and then use a tool, like js-builder, during the build process to combine and minify them. We actually output two files from the tool, one simply combined for debugging, and the combined and minified one for production use.