we are in process of switching our ASP.Net development from Visual Studio 2003 and .Net 1.1 to Visual Studio 2010 and .Net 3.5. So far, we successfully migrated our back end code and after some fight the ASP.Net front end code too. While the work on the back end code resumed with usual productivity, working on the ASP.Net front end code is massively hampered because of following issues:
The Visual Studio 2010 Web Designer crashes frequently (e. g. after using the "Undo" function) - we are used to the stability problems of Visual Studio 2003 Web Designer when working with large web forms, but the new Web Designer crashes frequently even with trivial web forms. Is there anything to make the thing stable? ServicePack 1 brought no help.
When adding new controls to a webform in the web designer, the declaration of the new control will never automatically propagate to the code behind page in the migrated web form. New web forms created from scratch seem to work ok. The migrated web forms maintain the old file structure (aspx, aspx.cs and aspx.resx), while the new web forms get a new file structure (aspx, aspx.cs and aspx.designer.cs. Recreating all the existing web forms manually to get the new file structure would be a very painful operation. Is there a way to make the old decent working propagation of controls' declaration to code behind file work in Visual Studio 2010 too?
(Currently our biggest problem): when designing a web form, we basically put the textboxes, labels, buttons etc. in a div with ms_positioning="GridLayout". We define absolute coordinates for every control in the div. This doesnot seem to work properly in Visual Studio 2010. With a lot of effort we can somehow continue using this approach, but adding a new button or textbox to a web form means massive effort now. Without paying really much attention it can even result in overwritig of the css-classes-file (the Web Designer sometimes decides to write the coordinates not in the aspx file but in the css file). I read recently that using absolute coordinates to position stuff on a web page is a very bad and deprecated approach. I tend to believe it seeing how gruesome it has to be done in the new Visual Studio. But what is the correct way to create winforms-like web forms rapidly? (With rapidly I mean simple drag-drop-point-click way of designing stuff).
Thanks in advance for any help.
Best Regards
Erich Horak
I'll try to tackle this issue by issue:
Designer
Unfortunately, the new designer in Visual Studio 2010 has been plagued with issues. With 2010, the editor was completely revamped with WPF, which was supposed to make it faster, but thus far has seemed inferior to the previous editors. There are some improvements, but if I had an option to choose I would stick with the old editor, at least until the issues are worked out with the new one. It may not be any consolation, but you are not the only one feeling that pain.
Adding controls/new page file structure
Again, this is another situation where migration will prove painful. If I were to suggest an approach, I would copy paste the markup into newly created forms (created w/ VS 2010). The designer.cs file should register the controls. You might run into issues with event handler mappings, but hopefully it won't get in the way of the designer.cs file registering the controls. I know this is a painful prospect, but you have to keep in mind that you're moving up several versions.
Designer view & absolute positioning
While you're migrating the system, you might want to set the default view to source-view, so you can paste the HTML onto the page. You can do this by going to Tools > Options > HTML Designer > General. Honestly, in my opinion, the designer is really flaky and should be avoided. The HTML it produces really is horrible.
Using absolute coordinates to position elements on a page is a deprecated approach for sure, but if your goal at this point is to get your migration working, then don't worry about it for now. Eventually, it would be a good idea to refactor your HTML and CSS to use more modern techniques, but if the current code-base is browser-compatible, then leave it for now.
It may not seem like it at first, but if you can move away from the designer and use the source view, you won't regret it. It does take a little more time at first, but having control over the markup will end up saving you a lot of time in the long run. If the designer is allowed to run rampant throughout the system, it will screw things up. By using the source view, you have full control over everything that's happening, which will become a huge advantage. By leveraging new features like master pages, you can move just as quickly in the source-code view as in the designer view of 1.1. I started out with the designer-view myself in 1.1, but after switching to the source-view, I never looked back again. You really do make up the productivity in other ways.
I wish I could give you a "do this and everything will snap into place" kind of answer, but I think you're in for a painful conversion process. The good news is, once it's done you can start utilizing all of the new features that have come around in the past 8 years. ;)
I see no quick, drag & drop way of doing this. Things like GridLayout are deprecated; much easier in the long run to port the forms manually, cleaning up the markup as you go and using the code view of the forms instead of the design view. Also an opportunity to write clean, separate CSS rather than inline styles.
Post 1.1, you do not need to declare the form elements in the code-behind - the new partial classes obviate the need for that. So this is just one more thing that is different. I am actually working on a similar project right now; I availed of the new master classes which meant changing quite a bit anyway.
My honest advice is to suck it up and move on :)
I asked a similar question here:
Visual Studio Multi-Project Solution Options
Related
I've taken over support of a legacy web app written predominantly in classic ASP. One page has a form for doing a job estimate, and consists of about 2500 lines of javascript and ASP code to achieve a "transparent edit" - i.e., the form is always in edit mode, and changes are instantly updated into the DOM.
There is also a "Print To Word Doc" button that, when clicked, goes to an entirely separate ASP file that produces (supposedly) the same view in HTML sent downloaded to a Word document.
The problem is that we have discovered inconsistencies and bugs in the two versions that are produced. My first response, applying the DRY principle, was This needs to be re-written in ASP.NET with a single code-behind file outputting the view for both the web page and the word document, so that we have one place to maintain the source.
However, upon getting into it, I'm questioning the wisdom of that approach, and I'm soliciting advice.
The problem is that, because of the integration of the view with the editing on the web page, as opposed to simply presentation on the work document, the two functions really do have two different purposes. Also, the ASP code, while ugly and hard to maintain, produces a reasonably nice-looking document. Doing the same thing in ASP.NET, at least using ASP.NET controls like FormView, is proving challenging. (One of the rewrite requirements is that the new page must function like the old page, minus bugs, of course.) The integration of the javascript to accomplish the editing functions on the client side makes for a good UX (assuming they work correctly). I can probably accomplish that same thing with AJAX and/or jQuery, but I'm wondering if I'm really gaining anything here.
How would you handle this?
You also have to take into consideration a couple of other issues:
How critical are the defects?
How
much time to do you have to get this
thing fixed?
How long will it take
you to correct the defects in classic
ASP?
How long will it take you to
convert the entire thing to ASP.NET?
At the end of the whole thing, will
anyone care which platform it's
implemented in? That is, will they
still be able to get their work done?
Because, at the end of the day,
that's all that really matters.
ASP.NET, while a wonderful thing, is not a silver bullet. If you're spinning your wheels, you're not being productive, and no one's getting a fixed product in a reasonable timeframe. It's like refactoring code just for the sake of refactoring it. It doesn't fix any defects, but darn does the code look pretty.
My advice to you: stick with classic ASP until you get the bugs out. THEN port it to ASP.NET. I'd much rather port a fixed product than a broken one.
That's a really complex question you're posing. The main issue is right there at the end:
I'm wondering if I'm really gaining
anything here.
Is the modification you need to make a small mod? or is it large? How much will you have to maintain this in the future?
You'll only realize dividends on your effort with future modifications. If you're never touching this system again, re-writing won't realize any benefits.
I have worked in projects in which we "converted" a classic ASP application into a .NET application. This is what we did:
Made a copy of the classic ASP files and then used the automated conversion feature from Visual Studio to convert this new copy into a .NET application.
Listed the .NET features we wanted to take advantage of in this new application and then found the correct places in the application to implement them.
Re-wrote code where needed to take full advantage of such features.
Refactored existing classic ASP code to avoid re-inventing the wheel where it was not needed.
Tested everything and then ran both applications in parallel until we felt comfortable that the new .NET application was running as expected.
I still find myself hand coding Visual Studio projects more than using the variety of UI-driven menus and dialogs. For example:
web projects: hand code html/css in Source View vs dealing with the Design View / Properties Window
flushing out class files: code by hand using stuff like the prop-TAB-TAB Create Property keyboard shortcut and good ole Ctrl+[X|C|V] instead of the Class Diagram feature
Do I need to give the dialogs and menus another shot, or is this the current state of IDEs? Intellisense is the best thing since sliced bread IMO.
Steve
I'd be quite content to have Microsoft remove the design view from Visual Studio. I find myself cursing it every time I accidentally hit the button and wait ages for the broken rendering engine to kick in. This is from the perspective of a web developer mind you - I'm sure it's essential for developing windows apps.
Generally I think most of the RAD tools are not particularly useful, and in the long run end up being problematic as they're not very flexible. When developing web forms asp.net applications the listview and repeater are generally the only controls that I use. Hand coding html/css would be the preference for most designers anyway. Tools like Dreamweaver are nice initially when you're learning, but you do get to a stage where you realise you're using them as a glorified text editor.
Intellisense as you mention is utterly bad arse, and the one thing that I would miss if I switched to something like e or Textmate.
I am not a .NET programmer, and I understand Visual Studio does provide a lot of nifty code generation tools. However, I think it's rather important that a developer knows the code in his application. If you feel comfortable hand-coding it because you feel more in control that way, I don't think that should bother you at all.
Also, as someone who writes a lot of HTML/CSS by hand, I know that Visual Studio's Design View does not churn out 'quality' front end code a lot of the time.
I personally hand code html/css as well as my class definitions 99% of the time. Exceptions would be things that would be hard to hand-code otherwise (does anyone hand-code WCF proxies?)
It's all about YOU. What makes YOU more productive. What makes more scenes for YOU.
It's good to know and learn alternative ways to achieve your goal. You can give it try but if it slows you down return to the way YOU used to code.
I certainly find the the UI designer only works for the simplest of pages, and even for them only for a few design iterations. I find this for two reasons
1) When laying out a page, there are often several legitimate choices, and I don't like the choices VS makes. For instance, it will set the width of tables using pixel sizes, while for most fluid pages percentages make more sense. Nothing wrong with what it does, but for whatever reason I find myself fighting it more often than not.
2) It hard-codes a lot of style information, and even creates synthetic styles in an in-page style sheet. I'd rather have a concise and comprehensive CSS for the site as a whole, minimizing overrides on each page (or in each element!). Again, I fight it more often than not.
Well the designer for WPF/Silverlight is pretty cumbersome to use. So I pretty much hand code xaml and C#. At the moment I do not do much asp but with MVC, I would assume I would hand code that.
With visual studio having intellisense for a lot different syntaxes now, it is easier then ever to hand code, well, code. :) I mean intellisense works for C#, CSS, javascript, asp, and XML (if set up right). It is pretty easy to code now days. The youngsters have it so easy now days. They do not know how hard it was to code back in the day.
I'd say it absolutely, 100% depends on what you're writing.
If it's a basic CRUD interface for a simple database, then I'd say yes, 80% is way too much.
If it's a Web Application with plenty of JQuery UI and no persistent data source, then 80% is probably less than I'd expect.
As Vadium said, it also depends on what makes you more productive. Personally, I fly along with Intellisense, but I'm not too good on using UI tools to build an app.
I always feel dumber using Visual Studio, but I have to finish my project sometime this century to get paid.
I'm struggling with a few in-house developers that are creating some web apps in VS 2008 using C#.
It appears that the native tools and components in VS 2008 are not being nice about creating Web Standard code.
For example, the navigation component creates items in its own table structure.
Is there anyway to make a web project from Visual Studio create nice, clean, browser friendly code?
You can use CSS Friendly Control Adapters to alter the output of the current ASP.NET controls. It's easy to set up and you don't have to change any existing source code.
If you're bound to ASP.NET WinForms, you could create you own set of controls or use 3rd party controls. There is also a XHTML configuration setting you could set to Strict, so that the controls try to render more valid core.
When you really want to write nice, clean, browser friendly code, you could take a look at ASP.NET MVC. ASP.NET MVC gives you complete control of the output, but that means you have to do all the things WinForms currently does for you, yourself...
Certainly. If a component doesn't produce markup you like, then you don't use it. It's just that simple.
Having said that, be sure to check out Visual Studio 2010 beta 1 to see if your issues have been addressed. If they haven't, then you get to complain about them in a way that might get them fixed.
VS 2008 web projects don't do anything web-standards-unfriendly. The standard ASP.NET controls (like the menu control you mentioned)? That's another story -- some use a mess of tables and javascript to do their thing.
The good news? You can use what you want of ASP.NET without having to use those controls if you don't want to.
Go MVC !!! you will have complete controle over your UI
My two cents: machine-generated code is almost never as standards-compliant as the code I write by hand, especially when you get into fancy widgets and whatnot. The obvious trade off is that writing code by hand can be tedious and time-consuming.
We've come a long ways since the dark ages of code-junk that frontpage or dreamweaver used to spit out, but even still...
In the end, your code is only ever as good as your programmers.
The Web Projects themselves are simply containers for the code that you create and a mechanism for managing and building the compiled project.
Based on my experience, the controls generated by VS comply to web standards ... that being said, browsers differ on which standards they do or do not enforce and how they enforce them. For the most part, you have a high level of control of the HTML that is output from your page. The table structure generted by the navigation control id valid HTML - you may be wanting to avoid the use of tables in which case, that particular control might not be for you.
For the most part, when you have a complex control you will need to take what you get - the HTML that is generated may not be intuitive to you and your team but that is often the price paid for the time savings gained by using a pre-built control, particularly one that is intended to service the needs of a wide variety of uses. (The same can be said for most code/script libraries you use/buy/find)
Many controls offer templating that provides you with the ability to define a template for how the resultant HTML is generated.
If you want cleaner markup, you have a few options:
a) Check out the CSS Friendly control adapters from codeplex. They help alot with certain controls.
b) Avoid the more complex server controls. There is very little one can't do nearly as effectively with a repeater and some user controls that one can't do with most any databound control for instance.
c) Try ASP.NET MVC. No neato server controls to do UI lifting, but it will let you make very, very clean UIs.
Our organization has dedicated designers who design the page and cut it up in Dreamweaver. That's worked well in the past with ASP and PHP sites. Now we're trying to make it work with .NET, but are struggling because of the structure of a project in ASP.NET. How does everybody collaborate with developers? The specific points I am looking for are:
-Transferring Dreamweaver content to Visual Studio
-Changing HTML inputs to server controls
-Giving designer access to finished Visual Studio product so they can tweak layout
Thanks!
Obviously, there will be a slight learning curve for your designers. But with that said, I have worked quite often with designers (none of whom used Dreamweaver, btw, so that may be part of the problem) on asp.net sites. Usually, they will create the HTML exactly how they want it on the server like a static HTML page, then I will go in and replace form fields manually with asp.net controls.
On an aside, I have found that I have the best chance of matching the design using controls that spit out the least HTML, such as Repeaters instead of DataGrids.
Once the site is up on the server and programmed, they can go back in an tweak things if need be.
Also, just like we have to adapt to them a bit (making our server controls spit out html how they like it) they also have to adapt to us a bit and not rely as heavily on id attributes in their stylesheets as some items id attributes will be controlled by hte .net runtime since they are controls.
MOre often than not, a designer new to asp.net will feel very threatened by this new way of doing things, specially with user controls instad of include files, but its really not that different than classic asp/php development is.
The key to the solution of all your problems in this matter is quite simple, and yet so hard to fulfill: it's usually called semantic markup. If you can make sure that the designers to start with make their html semantic, and that the .Net programmers keep rendering the same markup but with their server controls where needed, the tweaking won't be a problem - the markup is the same.
So what is semantic html, then? you may ask. Well, it's not always as simple as one would like it to be. A good start is to make every page pass XHTML validation.
In my experience, designer-created HTML almost always needs to be at least refactored, if not rewritten. So, open a browser with the original HTML on the left, and try to match it as closely as possible in VS on the right screen.
Giving designers access to ASP markup is not a good idea, imho. Too much can go wrong if you only understand half of the tags you are manipulating.
How about using one of Microsoft Expressions line of products? I've heard they are to .NET what dreamweaver is to PHP/ASP.
I am a c# developer.
Recently I had to design a web UI in asp .net 2.0 .I had strange problems with aligning controls in Visual studio UI.
I have used Div, table tags to align asp .net controls(labels, textbox, grid etc).
But the problem was what I saw in design surface of visual studio was entirely different (most of the time) when I view the page in browser.
The gap between controls and alignments was never perfect .I have seen other developers also doing trial and error methods without a proper guidelines.
C# coding I am pretty good and I have lots of Microsoft articles and help materials to guide me.
But I haven’t found proper articles and guidelines for UI design of asp .net pages.(may be its out there and i havent found yet?)
Can anyone through more light on this subject. Any good books ,suggestions etc?
Thanks in advance
SNC
If you want granular control over your HTML/XHTML output then I would recommend switching to ASP.NET MVC. The problems you've described are those typically encountered when using ASP.NET WebForms. As Anton mentions, you do need to gain a good understanding of XHTML and CSS as well.
While I definitly +1 everyone suggesting that you get a better grasp of CSS and positioning in general and ditch the drag and drop method of building your controls, I figure you need something sooner rather than later.
For that, I give you Yahoo!'s CSS Grids (JQuery, MooTools and other libraries also have grid layout tools) which will help you to get your UI done quickly. In the mean time read up on CSS.
(X)HTML is compositional - not unlike XAML (which is actually modeled on HTML/CSS). When building WinForms you can drag and drop your controls onto the window willy-nilly, but not so with the web. One thing the drag and drop designer misses is that (X)HTML components have a hierarchy to them. The designer tries to overcome this by using position: absolute; which is a precarious crutch.
Your controls need to be composed with their positional relationships more or less intact already and that means you'll have to edit the code by hand to put things in the proper order.
It's not the UI design per se. What you need is solid understanding of how CSS and generally styles work on the web (in short: they do poorly). So what you need is a good CSS book. Plus, you'll have to dump WYSIWYG ASP.NET page editor.
I'm curious if you feel your HTML skills are on par. Could you create this same page in HTML without visual studio and get the results you expect (using notepad)?
Regardless, start spending more time in the HTML markup and less time using the designer surface in Visual Studio. The more you understand the output that ASP.NET creates the better a web developer you will become.
A trick I use quite often is knowing that you don't need to recompile to change aspx code. Make your changes to the aspx file, save, and then refresh your browser. Also, use firefox and get the webdeveloper plugin. I use the outline block level elements quite often to understand where some of my html flow problems are occurring.
Read up on Web Design. I'm a bit behind but I've always loved zengarden and zeldman.. I'm sure there's better out there now.