C# and ASP.net Whidbey

re: C# and ASP.net Whidbey

Anatoly Lubarsky — Fri, 30 Apr 2004 22:42:00 GMT

Come on, I don't want to code like the old asp - all the things inline. It's insane, and you folks were talking about codebehind feature a lot before asp.net 1.0 and 1.1. and its benefits. So now you are taking your word back ? Listen, I just don't want to code inline I want back codebehind feature of asp.net.

re: C# and ASP.net Whidbey

Mikhail Arkhipov (MSFT) — Fri, 30 Apr 2004 23:55:00 GMT

Unfortunately, a lot of people do. So here you go :-). However, code separation is still there and it is default.

re: C# and ASP.net Whidbey

Anatoly Lubarsky — Sat, 01 May 2004 02:08:00 GMT

Mikhail:
Do what ? I played a little bit with technical preview, and I understand that default is inline coding for asp.net. May be I'm wrong ?

As far as I see there are lots of changes, but very little info about it over the net. There is much more info about longhorn instead.

re: C# and ASP.net Whidbey

scottgu — Sat, 01 May 2004 02:30:00 GMT

Code behind is still the default way to write ASP.NET Pages in Whidbey. But developers now have the option to choose single-file if they want to.

re: C# and ASP.net Whidbey

Anatoly Lubarsky — Sat, 01 May 2004 04:57:00 GMT

scottgu:
Are you sure ?
Have you seen technical preview ?
Some official document link that proves this ?

re: C# and ASP.net Whidbey

Mikhail Arkhipov (MSFT) — Sat, 01 May 2004 18:17:00 GMT

Scott definitely has seen it. He is ASP.NET product unit manager :-). I am dev lead in the Web Tools team. Yes, code separation is default. It is available in tech preview as well. I believe in earlier builds there were two icons in the New Web Form dialog: with and without code separation. Now there is a single icon and a "Place code in a separate file" checkbox at the bottom of the dialog which is ON by default.

re: C# and ASP.net Whidbey

Mikhail Arkhipov (MSFT) — Sat, 01 May 2004 18:33:00 GMT

Official link
<a href="http://msdn.microsoft.com/asp.net/whidbey/default.aspx?pull=/library/en-us/dnaspp/html/codecompilation.asp">New Code Compilation Features in ASP.NET Whidbey</a>

Scott's <a href="http://weblogs.asp.net/scottgu">Blog</a>

re: C# and ASP.net Whidbey

Mikhail Arkhipov (MSFT) — Sat, 01 May 2004 18:34:00 GMT

Official link
http://msdn.microsoft.com/asp.net/whidbey/default.aspx?pull=/library/en-us/dnaspp/html/codecompilation.asp

http://weblogs.asp.net/scottgu

ASP.NET in Whidbey

jaybaz_MS's WebLog — Sun, 02 May 2004 07:24:00 GMT

re: C# and ASP.net Whidbey

Guys — Sun, 02 May 2004 07:36:00 GMT

The consequence of that will be more massy code written by not experience developer

This is an open door for mistakes for lots of developers that still did not succeed to do their steps into OO.
Now they will have another, simple and easy to use option to spread their code - so without experience developer to guide them they will choose as default the simple option.

BTY - what is the advantages to enable inline code (I have some ideas but I'm not sure)?

re: C# and ASP.net Whidbey

Darren Neimke — Sun, 02 May 2004 10:19:00 GMT

Thanks for that entry, it's always interesting to hear about these little snippets of information from within the production teams!

re: C# and ASP.net Whidbey

Anatoly Lubarsky — Sun, 02 May 2004 12:27:00 GMT

To Mikhail Arkhipov:

Sorry, man - I have this checkbox OFF by default in my technical preview: I'm in front of computer right now :).

How could I figure out that you dev lead and scottgu is ASP.NET product unit manager, do you have a blog ? Scott's blog was not updated from december.

The article also does not speaks about this but about new compile model. It's also very single-sided. The bin directory had lots of disadvantages and the other approach has only advantages.

The inline feature would definitely encourige developers write ugly code that is difficult to maintain, imho

Microsoft listening ?

Anatoly Lubarsky Blog — Mon, 03 May 2004 00:54:00 GMT

Microsoft listening ?

Anatoly Lubarsky Blog — Mon, 03 May 2004 00:56:00 GMT

re: C# and ASP.net Whidbey

Paul Bartrum — Sun, 02 May 2004 22:46:00 GMT

I like the ability to code inline. It reduces the number of files in my solution by (almost) half. It's more intuitive (1 file = 1 page). Provided the editing experience is as good as with code-behind (I've tried the whidbey preview and it's very close), I'll definately be using it.

re: C# and ASP.net Whidbey

Anatoly Lubarsky — Mon, 03 May 2004 00:19:00 GMT

Paul:
>> It's more intuitive (1 file =
>> page).

You are wrong, more intuitive is code-separation. Ever used user controls/server controls ? Hey, it increases the number of files in your solution. 1 page = many files. And man according to you it is more intuitive to put business logic inside this file. 1 file = 1 page ??

C# and ASP.net Whidbey

Suzukiworks Web Log — Mon, 03 May 2004 06:04:00 GMT

C# and ASP.net Whidbey

re: C# and ASP.net Whidbey

RichB — Mon, 03 May 2004 16:51:00 GMT

If I work on a big project I use Code Behind. But if I'm just hacking up a 1-page site to show something like current build metrics - then I generally use a single ASP.Net page + <@Page src="..."> style backing class.

I just find it simpler to hack together something like this.

re: C# and ASP.net Whidbey

Michael Giagnocavo — Mon, 03 May 2004 21:50:00 GMT

I was really disappointed with the new system too :(. I *love* the 7.1 style and was more than happy to say goodbye to the hackish ASP/PHP/etc. style.

I really don't like having the "Code" directory and all that. The March CTP is rather broken so I can't tell what the actual intent is, but I'm really afraid that it's not going to be usable in the way I've been using ASP.NET.

I guess there were too many customers who think that HTML is a programming language :).

re: C# and ASP.net Whidbey

Ben Constable — Tue, 04 May 2004 00:03:00 GMT

Quite a few of our customers believe that HTML is a programming language, and we want to respect that. Visual Studio is used by a very wide variety of customers, and that is why there are options to do these things.

Remember that even if the default is not something that you like, it is only a default. Defaults will always be driven by what the majority want, not what we think people should do. Most people do not like tools forcing the "right" way to them.

re: C# and ASP.net Whidbey

Anatoly Lubarsky — Tue, 04 May 2004 00:19:00 GMT

Ben:
You completely miss the point. You can write html in both ways.
Concerning "default": remember, before .net 1.0 asp people wrote all their code inline (html together with server side), but nevertheless Microsoft came out with completely different model as the default way to write asp.net code in visual studio.
And the inventions and develoment is never driven by majority because majority just knows nothing about new things that belong to the future.

re: C# and ASP.net Whidbey

Anatoly Lubarsky — Tue, 04 May 2004 00:30:00 GMT

BTW, through this thread I've seen several times people speak about the "majority", many customers that want this way or that way. Hey be more specific, give some names, links, discussions. As far as I can see among people that are playing with TP, I can not say most of them don't like it or not, it is early enough, but the definite feeling is that MS takes its word back concernig ideology of development.

re: C# and ASP.net Whidbey

Ben Constable — Tue, 04 May 2004 00:53:00 GMT

Sorry, I was just referring to the code beside versus code behind argument.

The point I am trying to make is that in VS7.1 the support for code beside is not as good as it is in whidbey. In whidbey we are trying to make sure that both approaches work equally well, and letting the user choose which one they want. In VS7.1 we only offered templates for code behind, which kind of forced the hand for some people.

There is a difference between editor settings and what the platform and editor support. Using code behind or code beside is just a setting in whidbey - you are not forced to do anything.

Are you advocating removing code beside support completely? Or just removing code beside templates? I am unsure about what change you want in the product (if any).

re: C# and ASP.net Whidbey

Anatoly Lubarsky — Tue, 04 May 2004 01:27:00 GMT

Yes, I'm advocating removing code beside support completely, simple as that.

This blog and your blog are .text driven. And many others. If you've seen its sources there are many places where many user controls use one single code behind file for them.

At least don't make code-beside be default as it is now in technical preview. Now the realization is webmatrix style and I don't like that.

Suppose I don't write application from scratch but come to some company to finish some app. I come and see that it is written code beside. What should I do ? Get some tool to convert it back ?

re: C# and ASP.net Whidbey

Mikhail Arkhipov (MSFT) — Tue, 04 May 2004 02:01:00 GMT

Anatoly - the short answer is 'it depends' :-). If I write 30 lines C/C++ program, I probably won't bother to create separate header file. I'll just declare everything in a single file. However, if I am going to write 10000 lines app, I definitely will have separate header files.

Same for code inline. It is not different from client script, btw. If you have tons of script, you are probably using <script src="foo.js"> or some sort of include. However, if all you have is couple of onclick handlers code separation just adds overhead.

So long version (sort of): tool developers cater to users. We are not in position of requiring certain code writing style. We do give user an option to have code in a separate file, but if he or she does not want it - fine, we will handle code inline too. We are not advocating this or that style. Customer will make her choice. We are just making software and would like to sell more copies :-)

re: C# and ASP.net Whidbey

Michael Giagnocavo — Wed, 05 May 2004 16:02:00 GMT

I think code beside is fine, and will help people (and understand the business reasons for changing VS.NET around).

What I want is the old 7.x style of compiling all my pages and having ASP.NET subclass them at runtime (no partial classes). This way, I get compiler checking before deployment. As well, the content is separate and can be replaced separately from the code, and no code needs to be on the server.

I have one client, where I deliver just the DLL and a sample ASPX. He then goes and does his HTML stuff with the page. He doesn't have the source code. Can I still do this with Whidbey? More importantly, will VS.NET still make it easy to do?

re: C# and ASP.net Whidbey

Mikhail Arkhipov (MSFT) — Thu, 06 May 2004 02:32:00 GMT

There is new Build Web Site command that compiles all pages. I guess this is what you want.

re: C# and ASP.net Whidbey

Jiho Han — Fri, 07 May 2004 13:48:00 GMT

Interesting. I've heard so much about the new "Code Beside" feature of whidbey but I never knew that it simply meant an inline code block.

I think that giving people an option is always good. It's never good to have only one way of doing something.

That being said, as Anatoly has suggested - maybe unknowingly :) -, I would like a tool that converts the source from Code-Beside to Code-Behind and vice versa. I, like Anatoly, don't want to take over a project and find myself with mounds of Code-Beside files to deal with. If you're going to provide an option, you should make it complete. Especially when the tool isn't given out for free but gets sold for hundreds of dollars.

re: C# and ASP.net Whidbey

Jiho Han — Fri, 07 May 2004 13:58:00 GMT

I just remembered something and I thought I might just throw it in here as well. Does whidbey address the inability to create .netmodules or multifile assemblies?

Just wondering.
Thanks

re: C# and ASP.net Whidbey

Mikhail Arkhipov (MSFT) — Wed, 12 May 2004 05:57:00 GMT

Hmmm, I guess I was not clear. Code Beside DOES NOT mean inline script blocks. Code Beside means separate class file (i.e. foo.aspx.cs). Actually, we even limit support for server code in the aspx file in this case. For instance, you won't be able to generate server event handlers via dropdowns and double-click in Design view will generate code in the CS file, not in the ASPX file. It is pretty much Code Behind model except it is based on partial classes so no control declarations are requred (i.e. you don't have to declare

System.Web.UI.Button button1;

in addition to <asp:button id="button1" runat="server" />

Code Inline is a simplified model which does not requre .cs (.vb, .js) file and allows you to write server code in script blocks. It targets simple cases when amount of server code is small and placing it in a separate file create more hassle than necessary.

re: C# and ASP.net Whidbey

Mikhail Arkhipov (MSFT) — Wed, 12 May 2004 06:00:00 GMT

As for conversion, Whidbey includes migration tool that will convert Code-Behind files to Code-Beside when you open a project or a Web site.

Server code intellisense in Web Forms (new blogger)

Mikhail Arkhipov (MSFT)'s WebLog — Fri, 14 May 2004 07:06:00 GMT

Good site

Linda — Wed, 17 Jan 2007 14:34:49 GMT

<A HREF=" http://bonring.fire.prohosting.com/scarface_theme_on_mobile.html">scarface theme on mobile</A>

Good site

Linda — Wed, 17 Jan 2007 14:34:48 GMT

<A HREF=" http://bonring.fire.prohosting.com/scarface_theme_on_mobile.html">scarface theme on mobile</A>

Good site

Linda — Sun, 21 Jan 2007 01:15:12 GMT

<A HREF="http://entertop.info/scarface_rigntones.html">scarface rigntones</A>

kevinpilch bisson s WebLog C and ASP net Whidbey | fire pit

kevinpilch bisson s WebLog C and ASP net Whidbey | fire pit — Fri, 19 Jun 2009 09:11:07 GMT

PingBack from http://firepitidea.info/story.php?id=1520