We're in the process of redesigning the customer-facing section of our site in .NET 3.5. It's been going well so far, we're using the same workflow and stored procedures, for the most part, the biggest changes are the UI, the ORM (from dictionaries to LINQ), and obviously the language. Most of the pages to this point have been trivial, but now we're working on the heaviest workflow pages.
The main page of our offer acceptance section is 1500 lines, about 90% of that is ASP, with probably another 1000 lines in function calls to includes. I think the 1500 lines is a bit deceiving too since we're working with gems like this
function GetDealText(sUSCurASCII, sUSCurName, sTemplateOptionID, sSellerCompany, sOfferAmount, sSellerPremPercent, sTotalOfferToSeller, sSellerPremium, sMode, sSellerCurASCII, sSellerCurName, sTotalOfferToSeller_SellerCurr, sOfferAmount_SellerCurr, sSellerPremium_SellerCurr, sConditions, sListID, sDescription, sSKU, sInv_tag, sFasc_loc, sSerialNoandModel, sQTY, iLoopCount, iBidCount, sHTMLConditions, sBidStatus, sBidID, byRef bAlreadyAccepted, sFasc_Address1, sFasc_City, sFasc_State_id, sFasc_Country_id, sFasc_Company_name, sListingCustID, sAskPrice_SellerCurr, sMinPrice_SellerCurr, sListingCur, sOrigLocation)
The standard practice I've been using so far is to spend maybe an hour or so reading over the app both to familiarize myself with it, but also to strip out commented-out/deprecated code. Then to work in a depth-first fashion. I'll start at the top and copy a segment of code in the aspx.cs file and start rewriting, making obvious refactorings as I go especially to take advantage of our ORM. If I get a function call that we don't have, I'll write out the definition.
After I have everything coded I'll do a few passes at refactoring/testing. I'm just wondering if anyone has any tips on how to make this process a little easier/more efficient.
Believe me, I know exactly where you are coming from.. I am currently migrating a large app from ASP classic to .NET.. And I am still learning ASP.NET! :S (yes, I am terrified!).
The main things I have kept in my mind is this:
I dont stray too far from the current design (i.e. no massive "lets rip ALL of this out and make it ASP.NET magical!) due to the incredibly high amount of coupling that ASP classic tends to have, this would be very dangerous. Of course, if you are confident, fill your boots :) This can always be refactored later.
Back everything up with tests, tests and more tests! I am really trying hard to get into TDD, but its very difficult to test existing apps, so every time I remove a chunk of classic and replace with .NET, I ensure I have as much green-light tests backing me as possible.
Research a lot, there are some MAJOR changes between classic and .NET and sometimes what can be many lines of code and includes in classic can be achieved in a few lines of code, think before coding.. I've learnt this the hard way, several times :D
Its very much like playing Jenga with your code :)
Best of luck with the project, any more questions, then please ask :)
After I have everything coded I'll do a few passes at refactoring/testing. I'm just wondering if anyone has any tips on how to make this process a little easier/more efficient.
(source: cartoonstock.com)
Normally I'm not a fan of TDD, but in the case of refactoring it really is the way to go.
Write some tests first which verify what the bit you're looking at is actually doing. Then refactor. This is a LOT more reliable than just 'it looks like it still works.'
The other huge benefit to this is that when you're refactoring something which is further down the page, or in a shared library or something, you can just re-run the tests, as opposed to finding out the hard way that a seemingly unrelated change was actually related
You're going from classic ASP to ASP with 3.5 without just re-writing? Skillz. I've had to deal with some legacy ASP #work and I think it's just easier to parse it and re-write it.
A 1500-line ASP page? With lots of calls out to include files? Don't tell me -- the functions don't have any naming convention that tells you which include file has their implementation... That brings back memories (shudder)...
It sounds to me like you have a pretty solid approach -- I'm not sure if there is any magical way to mitigate your pain. After your conversion effort, the architecture of your app will still be messy and UI-heavy (i.e. code-behind running workflows), and it will probably still be fairly painful to maintain, but the refactoring you are doing should definitely help.
I hope you have weighed the upgrade you are doing against just rewriting from scratch -- as long as you are not intending to extend the app too much and you are not primarily responsible for maintaining the app, upgrading a complex workflow-based app like you are doing may be cheaper and a better choice than rewriting it from scratch. ASP.NET should give you better opportunities to improve performance and scalability, at least, than Classic ASP. From your question I imagine that it is too late in the process for that discussion anyway.
Good luck!
Sounds like you have a pretty good handle on things. I've seen a lot of people try to do a straight-line transliteration, includes and all, and it just doesn't work. You need to have a good understanding of how ASP.Net wants to work, because it's much different from Classic ASP, and it sounds like maybe you have that.
For larger files, I'd try to get a higher level view first. For example, one thing I've noticed is that Classic ASP was horrible about function calls. You'd be reading through some code and find a call to a function with no clue as to where it might be implemented. As a result, Classic ASP code tended to have long functions and scripts to avoid those nasty jumps. I remember seeing a function that printed out to 40 pages! Parsing straight through that much code is no fun.
ASP.Net makes it easier to follow function calls around, so you might start by breaking out your larger code blocks into several smaller functions.
Don't tell me -- the functions don't
have any naming convention that tells
you which include file has their
implementation... That brings back
memories (shudder)...
How did you guess? ;)
I hope you have weighed the upgrade
you are doing against just rewriting
from scratch -- as long as you are not
intending to extend the app too much
and you are not primarily responsible
for maintaining the app, upgrading a
complex workflow-based app like you
are doing may be cheaper and a better
choice than rewriting it from scratch.
ASP.NET should give you better
opportunities to improve performance
and scalability, at least, than
Classic ASP. From your question I
imagine that it is too late in the
process for that discussion anyway.
This was something we talked about. Based on timing (trying to beat a competitor's site to launch) and resources (basically two developers) it made sense to not nuke the site from orbit. Things have actually gone much better than I expected. We were aware even from the planning stages that this code was going to give us the most problems. You should see the revision history of the classic ASP pages involved, it's a bloodbath.
For larger files, I'd try to get a
higher level view first. For example,
one thing I've noticed is that Classic
ASP was horrible about function calls.
You'd be reading through some code and
find a call to a function with no clue
as to where it might be implemented.
As a result, Classic ASP code tended
to have long functions and scripts to
avoid those nasty jumps. I remember
seeing a function that printed out to
40 pages! Parsing straight through
that much code is no fun.
I've actually had this displeasure of working with the legacy code quite a bit so I have a decent high level understanding of the system. You're right about the function length, there are some routines (most I've refactored down into much smaller ones) that are 3-4x as long as any of the aspx pages/helper classes/ORMs on the new site.
I once came across a .Net app that was ported from ASP. The .aspx pages were totally blank. To render the UI, the developers used StringBuilders in the code behind and then did a response.write. This would be the wrong way to do it!
I once came across a .Net app that was ported from ASP. The .aspx pages were totally blank. To render the UI, the developers used StringBuilders in the code behind and then did a response.write. This would be the wrong way to do it!
I've seen it done the other way, the code behind page was blank, except for declaration of globals, then the VBScript was left in the ASPX.
Related
I would like to try developing ASP.NET and ASP.NET MVC apps in F#. I enjoy using functional langauges, and to my mind the functional paradigm fits better with HTTP and the web than imperative programming (though of course F# can do both).
I am only intending on trying F# for some personal projects, though I hope that eventually F# will be seen as a valid alternative to C# for suitable commercial ASP.NET projects.
What pitfalls and rough edges are there currently for using F# with ASP.NET? One obvious disadvantage is that F# is much more obscure than C#, so there are less code samples and experienced programmers for F#.
What other potential issues should I be aware of?
Personally I am a big fan of F#. My NDjango parser/rendering engine is written in F#.
But trying to do everything in F# can be difficult. To add to your list of the things which are not there yet:
There is no support for visual
designers - neither webforms nor
winforms. You can write the
appropriate code manually, of course
No Code Completion
Debugging in F# can be a challenge, in particular because of anonymous closures
Compiler Diagnostics can be misleading because of type inference - one typo can have profound impact in far away places
My biggest pet peeve is the 'file order matter' rule. You have to specify the order in which the files will be compiled
By no means this is a complete list. On the other end one might hope that some of these points will be addressed in final release.
Despite of all of the listed (and unlisted) problems I enjoy programming in F# - sometimes it gives a very refreshing perspective on the coding and I already started using some of the tricks inspired by F# in my C# code.
Just do not go crazy in it
Is this a home project or a work thing? If it's for work, you need to consider the ability of somebody else to drop in and maintain your code - there aren't too many F# developers out there when compared to competent C# people.
mmmmm f#, the other white meat that dare speak its name. Go for it, F# as Mr Kay would say "its the future!". As for the pitfall...puh!, what pitfalls, you just create stuff that works without chuff and Objects.
C# is great and it has its place. But as you correctly pointed out it does not suite web programming. In that matter neither does the event smoke and mirrors that ASP.net provides.
Go lower. Think HttpHandlers and REST. You don't need the MVC stuff. Its and Idea and not a product.
The front end GUI has nothing to do with the backend. Do you really need ASP.net? JSON/REST/POX.....develop your middle layer with these in mind and you should be ok. Stay away from WCF its propriety and nasty.
as for the comment of maintainable code. Trail blaze. why be what you don't want to be. If they don't think like you, then do you want them around?
When I work on projects the ideas drive the product not the technology and certainly not the masses or the mob. Large organizations cater for the mob for one reason only, and it has nothing to do with advancing the art and all about the Euro.
Messages and pipes are what I would use in this current climate. Events are great when the environment supports it, but does the async nature of the web lend itself to thinking of a processing pipe with clock ticks and checking if things have been done.
.Net good for one thing. middle layer with DB and logic. As for the front. Use something else. More webby.
Why just F# bring in the whole shooting match of best in class. plenty to choose from php, python, ruby,clojure, haskell etc....
F# is more than what it is, but what it represents, an old way of thinking in new and desperate times of multi-core multi-threading, multi-process.
As a song I once listened to said "I don't care about their different thoughts
Different thoughts are good for me"
http://codebetter.com/blogs/matthew.podwysocki/archive/2008/10/06/asp-net-mvc-with-nhaml-f-edition.aspx
http://cs.hubfs.net/forums/thread/6270.aspx
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
How effective is obfuscation?
Protect ASP.NET Source code
(Why) should I use obfuscation?
Is obfuscation the best answer for protecting our code ?
*Specially in Web Projects when you want to deliver your web projects as libraries of code to your customer ( the person who ordered ) *
Edited
At first my priority is Server-Side Code
and second Client-Side
but the main goal is when you want to deliver a complete web project
and you made every piece of your code as components and dlls now how effective can you protect them and doesn't allow others to make your code back from them .
Edited
The problem is that I want to protect the code that I'm written to a company that they ordered , now all my code are inside some DLLs ,
Now they can reverse engineer that and get my code , I want to prevent them from doing so ,
Is there anyway to do so or not ?
I think that is a unique question , And I didn't ask for what obfuscation is nor for tools of doing this activity , further than that I think this is apart from Client-Server Security
Sorry if my question wasn't clear at first , but if that is really a case to be deleted , no problem for me
Also
Also I wanted to have a comparison look at this problem and the solutions ,
because I think obfuscation wasn't the only possible solution at this , I think we can have maybe some logical sort of workarounds about this problem
Maybe not the best. If you are really ambitious, you can write your own web server (plugin).
But is it worth the effort?
Software is similar to a bike in the Netherlands, there is no known way of protection that is 100% safe. You use either a better protection than the other bikes (thieves are lazy). Or you must obfuscate the bike so they won't take it.
Another way to increase the level of protection is to use custom made ActiveX code to store mission critical algorithms. Of course, they can be reverse engineered, but javascript is easier.
What exactly are you trying to protect your code from?
Does your client-side code contain valuable business logic?
If not: you shouldn't bother obfuscating something that doesn't have much value. Personally I think clientside code theft is a something that people are far too concerned about. 99% of web apps don't really have anything special in terms of implementation on the client side. What you need to worry about more is someone ripping off the idea or visual look, which you obviously can't obfuscate.
If it does: you need to consider refactoring that logic out of the client side, as even with heavy obfuscation, a determined party will always be able to untangle it relatively easily. The code that adds real value to your app should ideally be running on your servers where it's considerably more difficult to get access to.
Even if people stealing your html markup or javascript was a something to worry about (and it probably isn't), obfuscation doesn't really solve the problem. In my opinion it is a waste of effort and money.
Hosting a critical function as a web service is probably the most sure way to protect it. It keeps the code out of the user's hands entirely. But then you're stuck hosting a service, and your users have to be on line to use your functionality.
Obfuscators help by hiding useful names and replacing control flow with weird but logically equivalent alternatives. They might thwart an amateur, but they'll only slow down a skilled reverse engineer for a few minutes, and they won't stop someone who is determined to penetrate your secrets.
I you really want to protect your code, you should write native code using a native code compiler (C++, Delphi). This still does not guarantee that your code is 100% safe because any experience developer can read assembler and essentially disassemble the native code program.
A determined hacker will always find a way to get to what they want.
The best we can do is to make it hard or painful for the would-be hacker to get at our code and the following options can help us:
Customize the CLR engine
Run an obfuscation tool over your code and use name and control flow obfuscation and string encryption
Make the application a Web-based application where all your proprietary code sits on a server somewhere
Watermark your code using your own custom techniques to "throw off" the would-be hacker
Implement techniques to prevent debugging (this is a very advanced topic!)
I really like a comment made by one of the head developers of the .NET framework where he said that he does not feel it's really the fact that others can get at our code that should be a concern to us, but rather, we should concern ourselves with the level of support we provide with our products.
So if we provide a good support base, it does not matter what the hackers do with our code, because the clients will trust us and our ability to support them using our product and not some cheap hacker-hacked program.
NO, obfuscation is not the best way to protect your code.
The tool you need to use is "copyright".
There is no (technological) way you can protect you code from someone determined enough (provided they have access to the binaries / scripts).
What you can do is prevent them from legally modifying/distributing your code.
The normal server-side code in Web projects should under no circumstances be visible to the outside world. So there is no point in obfuscating the code.
Besides that two minior points:
Javascript code is visible to the user and can be obfuscated. Minimizing javascript to save bandwidth is recommended anyway. Minimizing js also obfuscates the code.
Also important is that on production system the configuration setting customErrors should be set to RemoteOnly or On to avoid showing a stacktrace with to much code details.
If your client side code has any broad value to others, it will get reverse engineered regardless of any obfuscation.
The reality is that it's likely not going to be broadly useful to many and there is a lot of other code out there to look at so probably not worth doing more than minifying the code which is plenty of obfuscation and if your code is large, it will improve download speed.
Have you considered the alternative? That it's a good thing to give somethings back to the community? I'm sure you've looked at the code of more than one site, no?
This question is not coming from a programmer. (obviously) I currently have a programmer making a website for me and I am realizing that he isn't going to completely work out.
He has already done quite a bit of work and the site is almost there but I need someone who is better to take it the rest of way. The site has been done in asp.net and I am wondering how hard it would be for a more experienced programmer to take over and finish the work he has already done?
In general, is it hard for an asp.net programmer to come in towards the end of a project and fix what needs to be fixed?
There is five different pages on the site with two overlays for a signup and sign in. (Five pages with many different versions) There is a database and client-side scripting. AJAX was also used. It's a site somewhat similar to SO only not quite as complex and about something completly different. I would say think of something that falls somewhere between Stackoverflow and Craig's List. Thats all I can say now as I don't know the technical words.
You'll probably find that the new programmer will want to rewrite most of the code from scratch. If you are on a tight deadline or tight budget and can't accept a complete rewrite then you will need to hire someone that is not just good at writing good code, but good at reading, refactoring and improving bad code. It is two completely different skillsets and the second is much rarer. Depending on the quality of the existing code (and I'm assuming here that it is not good), your new programmer may end up rewriting much of the existing codebase just to understand what is going on.
Depends on how good the previous programmer was and on the complexity of the project. It might be anything between trivial (well commented source, some high-level docs, unit tests, modular or simple project), to "this crap needs a complete rewrite" (no docs, custom "let's try this" solutions, etc.). If you're not a developer it might be really hard to tell. And other people won't be able to answer without more details.
I'm no asp.net expert, but I suspect the ease with which the replacement will be able to finish the project will depend mostly on just how bad a job the first programmer actaully did. Bad code is painful to fix in any language. :)
A good idea will be to have them work together,for say, a week or two. This will help the new programmer get some much needed training about your current system.
You may find that although the site is almost complete, the successor will have to spend more time than anticipated when performing alterations, as this person will have the mental model of the software that the current developer has. Hence the need to next developer to "re-write" the code base.
If you can, you'll want to ensure that the code base that you have built is maintainable. That is, the solution is built in such a way that it can support alterations easily. As Mark Byers suggested, you'll want to get someone who can not only program but can also re-work your existing code with the goal being that someone else will inevitably implement future changes. If the software is something that you need to keep working for an extended period you'll want to make the investment in making sure that it new functionality can be added easily.
Remember this experience described at The Daily WTF. Take appropriate precautions.
Generally if the site is set up in some sort of standard fashion then another programmer should be able to pick it up easily. if the existing programmer did things to obscure the code then it will be hard for another programmer to pick it up. Basically the question is how readable is the code?
If the current programmer is unwilling to communicate the true status of the project in a professional, non-technical manner, then give him an ultimatum - your way or the highway. Odds are he will be more forthcoming if he knows you mean business. Make sure you have a copy of the latest code before broaching the subject.
It sounds like you are going to end up hiring someone else anyway, especially if you're asking these kinds of questions at this stage, so you might as well go for broke.
As Mark Byers said, it takes a seasoned developer to take someone else's code and resist the urge to "pretty it up" in order to bring the project to a working conclusion!
I just finished a small project where changes were required to a pre-compiled, but no longer supported, ASP.NET web site. The code was ugly, but it was ugly before it was even compiled, and I'm quite impressed that everything still seems to work fine.
It took some editing, e.g. to remove control declarations, as they get put in a generated file, and conflict with the decompiled base class, but nothing a few hours didn't cure.
Now I'm just curious as to how many others have had how much success doing this. I would actually like to write a CodeProject article on defining, if not automating, the reverse engineering process.
Due to all the compiler sugar that exists in the .NET platform, you can't decompile a binary into the original code without extremely sophisticated decompilers. For instance, the compiler creates classes in the background to handle enclosures. Automating this kind of thing seems like it would be a daunting task. However, handling expected issues just to get it to compile might be scriptable.
Will:
Due to all the compiler sugar that exists in the .NET platform
Fortunately this particular application was incredibly simple, but I don't expect to decompile into the original code, just into code works like the original, or maybe even provides an insight into how the original works, to allow 'splicing' in of new code.
i had to do something similar, and i was actually happier than if i had the code. it might have taken me less time to do it, but the quality of the code after the compiler optimized it was probably better than the original code. So yes, if its a simple application, is relatively simple to do reverse engineer it; on the other hand i would like to avoid having to do that in the future.
If it was written in .NET 1.1 or .NET 2.0 you'll have a lot more success than anything compiled with the VS 2008 compilers, mainly because of the syntactic suger that the new language revisions brought in (Lambda, anonymous classes, etc).
As long as the code wasn't obfuscated then you should be able to use reflector to get viable code, if you then put it into VS you should immidiately find errors in the reflected code.
Be on the look out for variables/ method starting with <>, I see that a lot (particularly when reflecting .NET 3.5).
The worst you can do is export it all to VS, hit compile and determine how many errors there are and make a call from that.
But if it's a simple enough project you should be able to reverse engineer from reflector, at least use reflector to get the general gist of what the code is doing, and then recode yourself.
As someone who has spent around 10 years programming web applications with Adobe's ColdFusion, I have decided to add ASP.NET as a string to my bow.
For someone who has spent so long with CF and the underlying Java, ASP.NET seems a little alien to me. How should I go about getting up to speed with ASP.NET so that I can be truly dangerous with it? Do I need to know C# at any great amount of detail?
I want to be in a position where I can build basic web apps fairly quickly so I can learn more doing the tricky stuff.
I'm only maybe six months down the same path, but here are some thoughts from my experience so far:
The C# language shouldn't give you much problem if you have very much experience with Java at all (or even CFScript). As a reference, though, when I was starting, I found csharp-station a good primer for language basics. It won't help you much as far as the ASP.NET side goes; but it is good for syntax. More you'll be familiarizing yourself with the .NET libraries. The IDE actually can be an enormous help here.
Here are the three biggest differences I found making the transition:
ASP.NET Server Controls - In ColdFusion, you really have pretty
direct control over the HTML; you
work very closely with the page.
This isn't so much the case in
ASP.NET. The server controls are
meant to relieve you of a lot of the
tedium, but at a cost of maybe some
direct control. As a CF programmer,
I'm very particular about what gets
actually output to the browser; and
at first ASP.NET frustrated me
because it spits out a lot of extra
code. Still, the controls are
really powerful, and it pays to
familiarize yourself with them.
Form and validation controls,
especially, save you from a lot of
the tedium in CF of handling post
back and validation. W3Schools
actually has a decent list of web
server controls.
The page model - ColdFusion is pretty agnostic in terms of page
flow. ASP.NET is very much geared
towards using post backs, and is
very event driven. If you're not
using a framework with CF (e.g.
Model Glue), this may be foreign to
you. .NET takes care of handling a
lot of the post back behavior for
you. Also, not to say that
ColdFusion can't be object and
function driven by good use of
CFC's, but ASP.NET really tries to
push you down the OO path compared
to CF in my experience.
Database access - Using ASP.NET really made me appreciate how
powerful cfquery really is. The
csharp-station site also has a good
tutorial on working with the native
.NET db tools. I haven't worked on
enough projects yet to start looking
around for DB access extensions; I'm
pretty sure Jeff recommended
something that they used for
building this site, so you might
check that out. Otherwise, I really
suggest you familiarize yourself
with the DataSet object. It's
somewhat similar to a query object
in CF, and lets you run query of
queries, etc... Looping over
queries in CF is very common, but it
doesn't happen nearly as much in
ASP.NET because of data binding.
Microsoft has a video called ASP.NET for ColdFusion developers you may be interested in.
Edit, here's another
ADO.NET is a core concept, and I would really recommend taking a course in it. Having a qualified instructor explain exactly what the differences are between a DataSet, DataReader (and so forth -- there are a lot of different data access object types) is invaluable. Not to mention you'll better understand the appropriate time and place to use each; and you can ask questions and get immediate answers in a classroom setting.
I took an ADO.NET class (one night a week, about 8 weeks) at my local university for around $400. Even if my company hadn't paid for it, I would have been happy to, and I can highly recommend anyone trying to learn .NET do the same.