It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Back in 2006 I've created a web site using asp.net 2.0. At that time, I had used Web Forms and classic ADO.NET SQL queries to connect to the underlying database. I've also used a fair amount of XSLT.
Today, the site still stands (it has gone through various upgrades but it is still based on Web Forms and simple SQL queries) but I believe it really needs to be upgraded as far as its technological infrastructure is concerned.
What is the next step I should take to move forward? A bit of ajax? JQuery maybe? Rewrite it in asp.net mvc? Replace SQL with typed datasets or even ling to sql? And what is the best way to embrace APIs such as twitter's?
So, can an old dog learn new tricks?
So why do you believe the site's infrastructure needs to be upgraded? If the site is running and performing well after 6 years of load and data, then what factors are causing you to think you need to upgrade it?
Are there features that you want to implement (or users are asking for) that you can't implement with the current infrastructure?
Is maintenance difficult and brittle, and every time you upgrade, you spend weeks fixing bugs introduced?
Are there integrations that you'd like users to be able to do so that they can extend your application's functionality and/or data to their own applications?
Those reasons above could be reasons to upgrade, but I can't really tell you.
But as far as some of your questions about what to upgrade:
a bit of AJAX? It depends on what your current infrastructure looks like, but it's not too hard to introduce and you can isolate it
pretty well with a service layer.
jQuery? Again, it depends on
how your pages are structured. If you have a lot of master page
re-written IDs and very few classes on your DOM elements, using
jQuery right off the bat may be tough as you'll have to figure out
how to get your selectors in line.
Replace SQL with Typed
DataSets? Please don't do that. Honestly, if you go with
Linq-to-SQL or EF, you'll probably take a slight performance hit
compared to using ADO.NET with DataReaders (if that's what you're
using).
Can an old dog learn new tricks? Always. The learning
never stops.
I would just advise not to upgrade just to upgrade. Make sure you have legitimate business reasons for doing so.
Hope this helps. Good luck!
Step 1) figure out what would add value for your users
Step 2) investigate technical solutions to solving those problems
Step 3) learn and build
You could create a persistence layer and learn about entities. This is an extremely useful skill to have. You could do this by using NHibernate. I would also throw in some LINQ to get a great combo. After this i would probably go to the GUI and do some needed features with jQuery
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
as the title says, I want to develop a browser multiplayer game with HTML5.
The game will be something like "risk", the turn-based strategy game. I decided to develop with HTML5 and the new canvas.
But the problem is on the server side. When I google, I only get answers, where people use "System.io", "node.js" etc. for that.
So my question is:
Is ASP.NET - especially MVC 4 - a bad choice for my purpose? I would like to do that with asp.net, but of course not when there is an easier/more suited option.
Some people say asp.net is not suited for that, it's too complicated and so on.
But I ask you pros out there :D
Would you consider developing a game like that with asp.net mvc 4 or better stick to other solutions with system.io and node.js and other frameworks? (php?)
I hope you can help my out, that stresses me for weeks now :(
Thanks in Advance!
Greetings from Munich
Tornister
Asp.net, especially MVC is well suited to develop an html5 based game.
A turn based game, is not very different from a web based chat. Where you send messages between members via the server.
To design a scalable solution, you got to use the right methods though.
You have various options to communicate between users.
Libraries like SignalR would help. If you do want to do it yourself, the most efficient method is to use a IHttpAsyncHandler and ajax requests. In MVC the equivalend it AsyncController.
Frameworks like node.js are designed to be async, and thus well suited. Php out of the box is not a good choice for such applications as it doesn't support async requests.
To sum it up, asp.net is not a bad choice, but you need to know how to use it. If you are more comfortable with another framework like node.js, then you should choose that one. Familiarity reduces a lot of development time.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm developing an ASP Web API project and using KnockoutJS as the client side technology. To the best of my knowledge there are no examples projects or any kind of sources available in internet for these two technologies yet. If someone has used these two technologies for their development, it is great if you can provide some links here (If there are online sources). I am posing this not as a question but to get some online sources about these technologies to one place (Because as I know there are no online sources yet). If someone know any sources about the projects which have used these two technologies in there architecture, it will be a great help for me (Since there are no online sources).
Thank you.
You should checkout upshot.js, Steve Sanderson's library for interfacing with WebAPI REST services. It is designed to complement knockout.js when building single page applications, facilitating communication between the view model (knockout) and the back end (WebAPI).
Here's a relevant SO post:
Where can I find Upshot.js examples and documentation?
I don't really have any links to share, but on the server side WebAPI outputs JSON by default and client/KnockoutJS side you are just consuming JSON. I use jQuery's .getJson() method and update my KO view model with the return data.
Check out John Petersen's blog for some good Web API samples.
Technically, Knockout.js doesn't help with accessing a REST API specifically Knockout with JSON. So, yea it works fine and I've used to with the Web API no problem. There is the Mapping plugin that helps with mapping the data to your view models which may be useful to you: http://knockoutjs.com/documentation/plugins-mapping.html
Backbone.js is meant to work with REST APIs (like Web API) and there is a project that makes Knockout work with Backbone (https://groups.google.com/forum/?fromgroups#!topic/knockoutjs/SAESwAqjfK4). I haven't used it so I don't know if it works well or not.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I know the differences between ASP and ASP.NET generally, as I am new to both, so I don't understand all of them, but I get the fact that ASP.NET is built on top of Microsofts .NET framework, and is the next generation of ASP, but it's built from the ground up.
W3Schools and another question here on SO provided great help explaining the difference!
I was wondering if it is worth it to fully learn Classic-ASP before diving into ASP.NET.
Why do people still use Classic-ASP? I've heard about the benefits which ASP.NET provides, and it seems like it would be worth it to switch.
Do people still use Classic-ASP because of server issues, or just because they prefer to work in it for some reason?
I would like some guidance on which I should start learning first, and why if anyone has any good suggestions?
UPDATE:
Thanks for the very helpful posts everyone! They gave me a great indicator of what is important, and why!
Thanks!!
There's little or no point learning classic asp as a precursor to asp.net as whilst similar in some respects(the Server, Request, Response objects and their associated methods, etc), they're different enough that one doesn't serve as a gentle introduction to the other.
If you've no need to know classic asp, definately go with asp.net as it's "the way of the future", be it in its MVC or WebForms guise. The only reason I can think of, now, to learn classic asp would be to support a legacy application. I'd be very surprised if there's any new "greenfield" development being carried out in classic asp on any great scale. There's also a great question (that I provided an answer to) that will give you some info on the differences between asp.net WebForms and MVC that's well worth a read.
When it comes to deciding "which language" out of the choice of C# and VB.net, pick whichever you find most comprehensible, at least initially. You'd be advised to at least consider C# as examples, samples, tutorials and suchlike are much more readily available in it. One look at the C# tag vs. the vb.net tag (105,977 questions against 10,815) here on stackoverflow makes it quite clear which has the broader uptake.
ASP.Net and Classic ASP really have nothing to do with each other. Yes, they are both technologies for building websites, but the relationship stops there. Incidentally, Classic ASP is more comparable to PHP than any .Net language.
Some people still have classic asp sites, but there aren't enough left to justify spending the time learning it... Unless you are already working on one. The main reasons any of those sites are still around is they still work (old bits don't exactly grow moss) and the cost to redo everything is high enough to not be justifiable.
Just learn C# and asp.net. Don't do VB.Net as it has a much smaller following.
I would so no, as classic asp is just going to teach you bad habits.
Unless you have to work on an existing projects that already uses (classic) ASP I don't think it is worth the effort to learn. You could save yourself a lot of headache by stearing clear of that rather dated technology.
Even though the templating engines have similarities you will have to code your (classic) ASP pages in VBScript or JScript. In ASP.NET you will be using C# or VB.NET. The .NET platform is much richer than the COM based scripting platform.
Don't bother learning classic ASP unless you know for sure that you'll be working with it. Personally, I wish I could forget it. Stick with ASP.NET. Microsoft won't be going back to classic anytime soon.
Only if it is a walk down memory lane that you seek, or if you are an unfortunate soul having to maintain ASP Classic web sites.
ASP.NET nicely balances dev productivity, ease of maintenance, separation of concerns, and performance issues which were present in ASP classic.
At the same time, you might look at the earliest CGI generators on Windows - anyone remembering sprintf-ing HTML from C++. Ouch.
http://www.west-wind.com/Weblog/posts/1143.aspx
Pretty much definitively not, no.
The last version of ASP was released nearly 10 years ago with a verison of IIS no longer being supported. All the various clones of ASP have also long since died, and basically the only reason it continues to exist is legacy support.
You do not want to base your future career plans on supporting dwindling and archaic code bases.
Platform itself isn't worth learning for new work--its ancient these days. It could be of some interest in a "understanding where we came from" and "understanding why all these old farts you work with have wierd self-defensive habits."
There is one good thing you can learn with it--how to handle classic HTTP request/response in the nude. ASP.NET MVC brings this back a little bit, but there is still quite a bit of abstraction and black magic surrounding it. Except when said magic fails and the abstractions start leaking and you need to understand the underlying transport . . .
Like everyone else said, the short answer is: "no", you don't need to learn classic ASP. The long answer is: even the most complicated classic ASP site should be rewritten in a newer technology, whether from Microsoft or someone else. Time would be better spent analyzing the old application to get a list of requirements for a new application and learning how to make it work with the newer technology. The fact that a company is still using a site that is 10+ years old and is hiring someone to support it instead of replace it should be a red flag for every developer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a small classic asp site and I am concerned that a client may stop paying me. The site is on their server, so I basically want an "off switch" in the event they stop paying me. I couldn't think of a good way to do this as they have a tech person who has access to the server, so any code I write to stop the site would be easily found and changed in the classic asp site (there aren't many pages).
So we had thought of maybe obfuscating the 2 main class pages so that they won't be able to edit the pages easily and we still have code to stop the site functioning. My questions are:
What is the best option for obfuscating classic asp code (if anyone has done this before)?
Is there another option that maybe we're not thinking of?
Thanks for any help you can provide!!
I think your energies are better placed on setting milestones in your project that are tied to payments. This ideally is done in increments so that neither party feels at a disadvantage with regards to the amount of work done / amount of money paid.
Obfuscation is easily removed and decoded, generally.
Remote checking for a security license opens a security hole for the application, and also can be defeated relatively easy.
Putting in code that "self destructs" if some action or code is not removed is also not great practice.
Licensed software is a little bit different in this regard. It sounds like you're building a bespoke system that you will simply hand over to the client at the end. If that's the case, putting in mechanisms to disable that system that only you control is not a great way to build trust. They may be violating trust if they fail to pay, but your disabling of the website actually gives them an additional incentive NOT to pay you, and consider you as a programmer willing to put in a Trojan Horse into the code.
The real problem to solve here is not in code, but in project management. A social not a programming problem.
This is a hard problem, and a great one for StackOverflow. I wish you well in sorting it out.
You're in Australia right? You have a small claims court system? If you've delivered what you were obligated to code for them, you shouldn't have a problem collecting.
I'm pretty sure that programmers have gotten sued or even charged criminally for this sort of thing; the courts see it as "hacking" into a client's site and breaking it over a payment dispute. Be careful.
I believe the best way would be to simply have it call your own server for some critical piece of data. That way you can restrict that service if / when their subscription does not tally with your desired business model.
It does depend a lot on the site, but there will always be something you can return from your own server to keep the site active. Also this does give you the advantage you are not disabling their server but your own if it goes wrong.
hope that helps
There is a tool from Microsoft called Script encoder that encodes a script into garbage, though it's fairly easy to get the original back..
Why not put some of the business logic into a VB6 component? That's valid optimisation and obfuscation in one. They could decompile such a DLL, but it's a lot of hassle.
More importantly, you need to consider who owns the code, regardless of what you do at this point. The link below is a discussion on code ownership in freelance situations (without a contract), and I think that the accepted answer defines the issues rather well: https://stackoverflow.com/questions/111815/freelance-work-with-no-contract-who-owns-the-code
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
This may be an opinion based question, but it's something that I wanted to ask (even if it does end up getting closed or deleted).
I do custom app dev (asp.net/aspMVC) and have absolutely no knowledge about sharepoint and was wondering:
If you have a "rock solid" custom app dev, asp.net/aspMVC web developer can he jump into sharepoint development fairly easily? What about the other way around? Does a seasoned sharepoint developer have the "chops" to do custom app dev using asp.net/aspMVC?
By no means do I want to offend any sharepoint developers or any custom app dev developers. I'm merely trying to see how much knowledge you can take with you when going from one type of development to another.
I recently put a very strong .NET guy from my team through the SharePoint learning process and let me tell you, it’s no small task. The issue is not so much familiarity with the SharePoint object model or product architecture (he was quite familiar with the latter), it’s more about understanding the “SharePoint way” of doing things.
Let me expand a little; the main thing is the concept of working locally on a host system goes out the window so you need to work on either a VPC (which you may need to build from ground up) or a server which also has the appropriate development tools installed. Some people even run a Windows server product directly on their host machine but you’d want to pretty dedicated when this also involves running SQL Server and SharePoint on your PC.
The next thing is it’s not simply a matter of opening up a SharePoint site and writing code against it, it’s more a matter of building individual webparts and features which can then be deployed. This also involves some very obscure configuring of XML files which if done incorrectly, can have a very negative impact on the entire environment (i.e. things just stop working). Finally, the deployment process is completely different. There is no simple “publish” option like you’d have with a normal ASP.NET environment rather there is a convoluted process of deployment and activation.
SharePoint does a lot of things really well but when it comes to writing custom applications it has an uncanny knack of making things that are normally very simple extremely complex. You reach a lot of crossroads where it’s either the SharePoint way or the highway and if you’re not aware of these upfront you run a serious risk of the effort required blowing out significantly. Don’t get me wrong, it’s a great product, I’m just saying don’t approach it with the attitude of “it’s just .NET development” and expect things to go smoothly.
IMHO, this is a very large jump for a .NET developer and shouldn’t be approached unless you’re serious about moving into SharePoint development. I’m quite explicit in my environment now that unless someone has real world experience developing for SharePoint they should not be jumping in and “learning on the job”; the risk is just too high.
BTW, there is a good question titled What are your biggest complaints about Sharepoint which you should read.
I know a (little) about SharePoint and to a large extent you can pretty much code in SharePoint if you are a .Net coder.
There are a (lot) of quirks you need to be familiar with though.
WebParts for one. These are
available in WebForms but they take
on new meaning in SP.
How and Where the pages are stored.
SP, if you make a change to a
standard page, stores the changed
page in a database and references it
from there so if you go looking at
your file system for your file,
you'll find it but it'll be the wrong
one.
I think the page life cycle may be
slightly different but don't quote me
on that.
That's just to name a few.
To sum up though I don't think you can just dive in and begin coding. I think your best option is to either get a SP developer to teach you or to do a course.
I did an SP course and to be honest I still don't think I could just dive right in and get it right.
SP punishes you harshly when you don't do things the SP way.
I am in this position and getting into MOSS (am certified for configuration) but it is not easy to understand as there are new concepts when developing for MOSS (eg webpart production). BUT it is just a new process and a lot to understand about MOSS and how it works.
My limitation is not doing enough of Sharepoint 2007 at work so obviously I am going to be lagging behind in webpart creation, etc. But this is why I am going to install the software at home.
On the other hand, Sharepoint development is C# and ASP.NET, so in the codebehind/presentation, you have a solid base.
If you code Sharepoint, I think Winforms is easier so you can switch to that ok. ASP.NET and Sharepoint 2007 share A LOT of concepts as Sharepoint is pretty much a very advanced ASP.NET web application so you can go from MOSS to ASP.NET.
I develop Sharepoint applications since 2002 and ran successfully dozens projects based on it, ranging from .
Starting with WSS 3.0/MOSS 2007 most Sharepoint specific technologies (aka webparts) was incorporated into .net; so, application development changed a lot: you don't need to eat SPWeb on breakfast, but being a regular ASP.NET developer and having a pragmatic approach to learn about content management it's enough.
Bottom line: Sharepoint development isn't rocket science; don't be afraid, get a VS2005/8, a VPC and happy coding!