ASP.NET Local Development Setup - asp.net

I would like to start learning ASP.NET on a for-fun project. I'm hoping to setup a local server to do my development on, but I don't want to pollute my user account with a webserver, database, and developer tools.
I'm using Vista Home Premium as my desktop OS. Is it possible to setup a separate user in vista and contain all the developer stuff inside it? (Keep sql server, IIS, and Visual Studio separate so they don't run when I'm not doing development work)
If this isn't possible can someone suggest a good alternative?

Use a virtual machine such as VMWare.

I personally don't see any benefits of creating a separate user for this. There's a webdevserver bundled with VS for development use. This only runs when you start it. And VS itself doesn't do anything unless you are using it...
SQL Server can be set to be started manually.
If you're just getting started, check out the express editions of visual web developer and sql server.

I agree with ocdecio: a virtual machine is the way to go. The nice thing, as well, is that you can take a few hours to configure your development environment and then save it intact. That way, if you ever hose it, you do not have to spend another day configuring it. Think of it as "Environment Management" to go along with your Source Code Management. The only caveat is to make sure you have plenty of RAM (2+ GB). RAM is much cheaper than time these days!

I have to agree with the above.
I have all the dev stuff on my one user account (I'm using Vista Home Premium too), but nothing runs unless I ask it too.
When installing Sql Server, you should be prompted if you want the service to start automatically or manually. Choose manual and run off one user account.

#mdbritt
This case is a development learning env for asp.net. I can hardly believe that a virtual environment is preferred for this. Nor for any other normal development environment.
Why not just create an image of the hard drive if you want to avoid time spent on reinstall and reconfigure?

I agree with ocdecio: a virtual machine is the way to go. For some things, you can even download fully functional VM's direct from MS (ie Sharepoint Development). The VM's can be a real timesaver and they're easy to backup in entirety.

Related

Setting up a new team work environment for asp.net

We own a small company and develop asp.net websites. Here is our work procedure:
We have a server at the company with Sql Server 2008 and IIS 7.5 installed on it. All our projects including the database and website pages are on the server. We connect to the server and edit the files using FTP, so any change to a web page can be seen at once. The programmers (less than 10 programmers) connect to the server using Visual Studio 2010.
Now we want to include source control system in our work. The problem is including a SCM in our work requires changing our way of working.
Does anyone have any advise on setting up the working environment?
Thanks in advance.
You first need to decide on what type of SCM you are going to use - centralized or distributed.
One centralized SCM is TFS - this is from MS and integrates very will with VS. I believe there is an express (basic) version that is free, but the other editions are quite expensive.
An easy and free centralized SCM to start with is subversion - you can install the SVN server on your server and setup a client for each developer.
A distributed SCM does not have a server - a popular one is GIT.
Do read up on all of these before deciding. You will also have to figure out a good workflow for your team. Start with a small project so you can gain understanding and minimize the cost of mistakes.
So many ways to do this :)
One way is to use something like http://beanstalkapp.com/ to store your source code under SVN. Each developer then has a local copy of the code to work on and a good history of changes is kept when developers commit their code (at least daily), and these changes can be emailed around to the team if you want them to be. One member of the team is then tasked with uploading the latest SVN code to the testing server once it's tested and approved locally (probably at the end of each day).
I'd recommend your developers install http://www.visualsvn.com/visualsvn/ Toolbar into Visual Studio if you use SVN.
As an alternative to hosting your SVN repository with someone like Beanstalk, you could use the free http://www.visualsvn.com/server/ which cuts out the need to upload the latest code to your testing server, as it'd be stored right there and updated on each SVN commit. But this adds an overhead in terms of backups etc.
Let us know what road you go down in the end.

Leading the jump from Classic ASP to ASP.NET, any advice?

I just started at a new company that has 99% of their code written in classic ASP (most of it poorly written) and part of the reason they hired me was because I had worked with both ASP and ASP.NET in the past. The ASP.NET experience was VB.NET but I've worked with C# in college but I prefer it just because I've worked a lot with PHP in the past and when I'm not focusing I just start typing C syntax and have had many occasions here in ASP where I end lines in a semi colon just out of habit and have to go back and delete it.
But I digress, basically I just don't have the knowledge I need to make the best decisions on things have made notes of some key processes that I'd like advice on:
Version Control - truth be told I've never really used it. On my own I just never had that whoops moment to push me to use it and shops I've worked in have always just thrown caution to the wind. Would like to know what you all think I should use as far as the server side and
Local Dev Environment - Probably something I'll just quickly Google but I want to setup a local dev environment so I can test stuff without having to FTP it somewhere first.
Pushing Changes Live - I've never really understood the step between checking something into version control and seeing it live, is there some sort of automated system that can go "hey I see you checked in, let me see what's different between this and the live version and push the affected files" – possibly just a lack of vc understanding all together: (
IDE - Downloading VS2010 Beta 10 now, hoping it's stable
MVC.NET - Easy to pickup? I always hated the whole concept of Web Forms, seemed like it didn't ultimately fit the Internet the rest of the world is developing.
Anything Else - Like I said I'm relatively new to this stack so I'd love any advice I can get early on to avoid any "shit, I wish I knew that 3 months ago" moments.
Version Control:
Definately have a look at SubVersion, its free, we use a paid-for hosted service called Assembla (www.assembla.com) but you can install the server on your network. Themost popular client is called TortoiseSVN (http://tortoisesvn.tigris.org/) its also free.
You can also have a look at VisualSVN (http://www.visualsvn.com/) which integrated into the VS IDE, their site also has a handy SVN server installation.
Local Dev Environment
Local IIS or Built-in VS web-server in VS are both fine, it really down to preference I think. Opening a website (File-system based) rather than IIS based seems to work quite well for us.
Pushing Changes Live
ASP is very page by page based development and doesnt require compiling, copying files up to a test or production site is quite easy. Depending on how you compile/publish your asp.net site, you will need to consider how you compile library code and publish your web application/website.
I would recommend starting off by using SVN to commit changes and to update test/production sites.
IDE:
I would recommend updating to the latest Beta version of VS2010 and use that.
Anything else:
Consider the rollout, are you replacing everything before going live?
Consider adopting an existing framework, use an ORM, or Business Objects framework, possibly even use Code-Generation. Have a look at CodeSmith, it has various ORM/Business Object Frameworks associated with it. (these will use various teqniques and technologies in the .net framework, which you will need to learn)
Look at the basic structure of the site:
Consider asp.net WebForms (Applications) or MVC (Websites) [yes, this is a very basic analysis of the differences]
Site Membership and Permissions: Have a look at the MembershipProvider, RoleProvider and build your own.
File System: Consider how and where you will upload files.
Separate UI into re-usable UserControls.
HTH, Good Luck you have a lot to do...
Wow. lots of questions here:
Version Control - Look into Subversion and Git. They represent two kinds of version control, you might like one more than the other. Git is free for open source projects.
Local Dev Environment - I would recommend using the built-in web server in Visual Studio. You can right-click a page in your solution explorer and say "view in browser". Then it will just compile it right there and open up an instance of the local web server.
Pushing Changes Live - I am not gonna offer advice here. Someone smarter than me will surely do so.
IDE - Yeah, just stick with the current version of Visual Studio. If you don't have any active (for pay) projects, I think the VS2010 is a good idea because it supports the newest upcoming features of asp.net and by the time you learn them, it will probably be released to the public anyways.
Anything Else - It's worthwhile (from getting work perspective) to know WebForms in and out. But I would highly suggest learning ASp.Net MVC (if, for no other reason than, "it's more fun").
After reading Mark Redman's answer, it triggered something for me. I would recommend (as he does) that you investigate some sort of ORM. I use SubSonic and really love it. Bu t there are lots of options out there.
Those are my 2 cents.
I'm going to focus on versioning and project tracking here. Development environments for ASP.Net are well documented.
Version Control - I use SVN (version control) with Tortoise SVN (windows client integration) and Trac (project tracking). SVN and Trac both run on Apache (a web server).
Pushing Changes Live - Commit your changes to SVN from your dev machine, do a SVN update on your test site to pull down the latest changes from the repository, run tests, then do a SVN update on your production site.
Anything Else - In this scheme Apache, Subversion, and Trac will be running on a server that is NOT your development machine and hopefully (but not necessarily) also not the same server that is running your production IIS.
Check out:
Apache HTTP server: http://httpd.apache.org/
Subversion: http://subversion.apache.org/
Tortoise SVN: http://tortoisesvn.tigris.org/
Trac: http://trac.edgewall.org/
One thing to take account of is basically going from Classical ASP to ASP.NET is about as similar as going from COBOL to ASP.NET. Everything will basically need to be a complete rewrite (especially as you said there were poor development practices in the original codebase)
Version Control: Definitely use it, there's also Team Foundation Server which if you can convince the company in the value of purchasing you a MSDN subscription TFS is included at no additional cost for 5 or less users.
Pushing changes live: I currently use Web Deployment projects (not sure if they're compatible with VS2010), TFS is also a build server I just haven't had time to setup the responsibility for that. If you take advantage of TFS fully I'd also recommend looking into a continuous integration (CI) tool something along the lines of Jetbrains's TeamCity or CruiseControl etc.
Local Dev Enviroment: Get Jetbrains's Resharper! This is the number one most important tool to developing software in .NET second only to Visual Studio itself!
Anything else: Learn generics and lambdas/expression trees both are integral to proper software development in .NET and both are moderately to extremely complex topics (IMO).
Version control: I see many recomendations of SVN here but... it's just outdated. Use GIT or Mercurial. They merge algorithms are more robust. The are faster and safere because they are distributed. They are more flexible - you can construct a workflow model that suits your company well while there is basically one way of using SVN.
Pushing changes live: After you have version control, the next thing to do is making a Continous Integration server thah repeatedly checks out repository and perform automated build. You can get immediate information who and where made an error. You can make this build do anytking you want: perform static code analysis, unit tests, deployment. You can make several builds - one, automatic, that builds a project and deploys it to a testing environment. And another one, triggered manually, that will deploy to live. I worked with Hudson, Jenkins, CruiseControl.NET, TeamCity and I've found TeamCity to be the most user friendly tool of that four.
Local dev env: Althoug IIS Express (that Visual Studio built-in) is OK in many cases, you have to know where it differs from the 'real' one. I would just recommend using the full IIS 7.
IDE: Visual Studio + Resharper + Notepad++ + LINQPad.
Anything else: Have some bug tracking/planning software. Even as simple as http://www.trello.com, but use it. My favourite is http://www.pivotaltracker.com
Introduce code review into the workflow. http://www.reviewboard.org might help.

How can we use version control in a shared work environment?

Currently our team (web devs, one designer and one copywriter) all work on separate workstations but do our changes on the same dev environment (we all mount the same shared drive), it's a marketing site and not a web application, so no builds or deployments, we just push changes to the live site once they are done, but I think it's important for us to keep versions of files, especially serverside code, even if it only makes up a tiny percentage of our content (mostly static pages).
I'd like to use version control for our work setup, but I'm not sure if SVN or GIT will play along with more than one person checking in/out from the same dev environment. I've got existing experience with SVN, CVS, GIT, Perforce and PVCS but have always worked with individual dev environments.
I'd like a solution that doesn't require us to run separate dev environments as we lack the infrastructure.
Most, if not all, version control implementations are intended to be used by more than one person. Both Subversion and GIT will happily do everything you require but you might find Subversion easier to get up and running with quickly. If you intend to host it in a Windows environment, take a look at VisualSvn Server.
The major difference between GIT and SVN is that GIT is a distributed system whereas SVN relies on a central repository. In software development, there are good arguments for using a distributed system but the needs you describe would be easily served by the much simpler SVN implementation (I think).
Another good reason for using SVN (under Windows) is that the TortoiseSvn client is one of the best examples of a user interface to any version control system. It is extremely easy to learn how to use and well documented as well as supported by the OS community.
It may also be worth investigating the various providers of hosted version control systems if you don't want the overhead of maintaining your own source control servers.
You don't need lots of server hardware. Why can't each dev/designer/etc run the site on their own computer? You do have atleast one computer each? :)
GIT or SVN in that case is just a matter of taste.
the way we used to do this at an old workplace was to give each user an account, and give the "project" and account as well. We would each check out a local working copy. the project (in your case it would be the tools that people in your business use i guess) would check out a copy too. Once the devs were all satisfied with a certain build, we would issue an update to the project working copy.
In your setup you say that you all have the same dev environment. do you mean you each have your own PC on the network, or are you sharing a PC? either way you should be able to each have your own svn accounts and local working directoires, so this would not be a problem.
Depending upon the amount of data you are talking about, an option to consider would be Dropbox ("secure backup, sync, and file sharing made easy"). It supports versioning, and lets you share folders.
It also has the benefit of providing offsite backup of, and remote web access to, your data.
With svn, you can have each submit automatically trigger an update of the live site. Still having everyone work in the same directory is somewhat awkward (as it was all the time, anyway …), but old habits die hard and assuming people insist on that, svn does export its repository via WebDAV, so it should be possible to mount it as a network filesystem on the desktop machines.
"Currently our team (web devs, one designer and one copywriter) all work on separate workstations but do our changes on the same dev environment (we all mount the same shared drive)" Adding SVN would do away with the need for the shared drive. You would each work in a local directory that is checked in to SVN. Tortoise would be a perfect client for you.
"it's a marketing site and not a web application, so no builds or deployments, we just push changes to the live site once they are done" A simple batch job (ANT script or other) could be written and given to each of you. Once the files are ready for deployment simply execute the batch and have it check out the latest files from SVN and copy to your web server.
"doesn't require us to run separate dev environments as we lack the infrastructure"
Doesn't make a lot of sense.
Presumably, each of you has a separate workstation. And your workstations are separate from your web server. Just guessing, but that's typical.
You can -- trivially -- each have a private development copy on your workstations. You can then use SVN to synchronize your various changes.
You can tag a version as "good to go".
Someone can -- when you've got everything looking right -- do an update on the web server to get the official version into production.
This doesn't require any more infrastructure than you already have in place.
With SVN you can have the devs commiting to the server, and have one special user at the server checking out the latest version. So commiting you work involves commiting to SVN, then logging in to the server and do a checkout of the latest trunk.
You can use the same pattern with git and other decentralized version control systems. The advantage with these systems is that they don't enforce the central server pattern. Dev a could for instance push to b which then pushes it to the server.

Advatages to using virutalization for web development

It's one of those things I see a lot but never really think of. Do you think for the purpose of web application development (specifically ASP.NET WebForms/MVC). Do you think it's advantageous to do such a thing and if so, what kind of advantages come out of it?
By virtualization I mean using products like Hyper-V to separate the server context like your SQL and Web Server, etc.
First question is, virtualization of what? Do you mean server virtualization? Do you mean running VMWare on each dev's laptop with multiple OSes? Do you mean moving everything to the cloud?
Virtualization of servers, in web app context, is not really different from that in general IT - most of the servers on the Internet, including StackOverload's, are bought to handle peak loads and spend most of the time idling away the cycles, so virtualizing them makes sense when you have more than a certain amount.
VMWare on the desktop (or other parallels on other operating systems) is superb because a) your devs can run a full instance of your server environment, including multiple virtual servers connnected in a virtual network - this is about as close to the real thing that you can get, minus hardware costs and minus devs messing with each other's servers. For clients, you can use Linux and multiple Windows installs to test various browsers, font sizes, etc. quickly - also a big win.
Moving everything to the cloud makes sense in many cases, but is probably a topic for a separate full-sized question :)
One big advantage I see is, that every developer can have his/her own sandbox to work on. If someone messes up his/her sandbox he/she can take a clean image and all is OK again. So I guess that means that there is room to experiment without losing valuable time getting back to the normal setup, you can simply do a rollback.
I'm in doubt a bit on whether you should use virtualisation for production environments. Depending on the application of course.
The only time I would use a virtual for ASP.Net development was if the app required specific setup, such as relying on installed software, wierd settings or particular shares. Every developer has their own webserver and can run their own database so if it's a "basic" webapp I don't see much value in virtuals.. it's pretty hard to break anything with a basic web app deployment :)
With a virtual server, you can test your code in a production-like environment. It is also possible to quickly revert back to the original setup. For many applications, it is useful in that time period just after you write the code, but before it goes to production.
I'm a fan of virtualizaion and use it in testing and production (VMWare and Hyper-v) but over the last year I find it less important on a dev machine. TFS provides me with all the backup/rollback ability that I need, multiple versions of .net can now exist on the same machine and VS2008 can target all those versions.
In a development environment a virtual environment is useful to put several different servers on one box, you can have an instance for your web app, one for your services, one for database, etc. That way it mimics your production environment if you are using separate servers.
One of the benefits of using virtualization in production is that your application is not tied to a specific machine. If you wanted to move your web server instance to another box, it is trivial to do so. You don't need to install or configure things on the new server and hope that everything is set up properly.
One problem I have had though in testing virtual instances is that it can run slower for some applications, specifically engineering apps that like running the CPU at 100%. So test before you leap.

"simple" installer for a web application (IIS virtual app + sql server db setup)

I need to create a web application installer.
Install Shield seems like overkill, is there something that can reliably install a web application (IIS setup + sql server db setup).
Suggestions?
CruiseControl.NET (http://sourceforge.net/projects/ccnet/) uses NullSoft's NSIS for this. It does a good job and it's free. The installer setup scripts, including the VBScript program that sets some of the website characteristics in IIS, are all in the source tree (http://ccnet.svn.sourceforge.net/viewvc/ccnet/trunk/ccnet.nsi?view=log and http://ccnet.svn.sourceforge.net/viewvc/ccnet/trunk/install).
Have a look at WIX, schema help, it can do what you want and so much more ...
InstallShield or one of its competitors is the simple solution anything else is going to require you to know way to much about msi(and that is a major headache).
I currently favor Advanced Installer they have a free edition. I believe InstallSheild has a free version as well, I just don't like the InstallShield product any longer and it bothers me that their holding company practacly changes every year.
I can only second NSIS (Nullsoft Scriptable Install System). Supports scripting and is easy to set-up.
installshield is a good way to do this. handles sql server setup and iis config fairly well.
not cheap though I'm afraid but worth it for any type of install. wix might be an good option but how much time can you afford to spend on learning it rather than clicking some wizards in installshield.

Resources