Disadvantages in Visual Studio 2005 (Web sites)

[Guest]

Thanks for your test, but it still doesn't work.


These are my steps:
remeber that I'm using a C# Web Site
In VS, right click App_Code and then "Add New Item"
selected Dataset in the templates window, and wrote "Foo.DataSet1.xsd"
instead od "DataSet1.xsd"

The result is a class with Namespace called Foo, but the class name is
called Foo too!!

This is the vs generated code of the DataSet:
namespace Foo {
using System;



[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "2.0.0.0")]
[Serializable()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.ComponentModel.ToolboxItem(true)]

[System.Xml.Serialization.XmlSchemaProviderAttribute("GetTypedDataSetSchema")]
[System.Xml.Serialization.XmlRootAttribute("Foo")]
[System.ComponentModel.Design.HelpKeywordAttribute("vs.data.DataSet")]
public partial class Foo : System.Data.DataSet {
..
..
..

2. This confirms that Vs2005 Web sites don't support namespaces

 

[gerry]

please open up vs 2005 and try this for yourself
mark is absolutely correct, web forms have the subfolder prepended to the
class name in vs2005.
/default.aspx - class = _default
/subfolder/defualt.aspx - class = subfolder_default
/subfolder2/defualt.aspx - class = subfolder2_default

 

[Scott Allen]

Thanks for your test, but it still doesn't work.

Ah, I think I found the culprit.

1) Go to App_Code and add a new Item named "Foo.DataSet1.xsd".

2) Observe the generated DataSet is Foo in namespace Foo (Foo.Foo).
There appears to be a bug in the VS2005 xsd template.

The reason it worked for me is because I did:

1) Go to App_Code and add a new Item named "DataSet1.xsd".

2) Right click "DataSet1.xsd" and rename to "Foo.DataSet1.xsd".

3) Observe the type now has the desired name and is in the Foo
namespace (Foo.DataSet1).

What's the difference? Three attributes in the opening xs:element tag
of the .xsd. The item template is not putting the correct name in
these attributes. Fortunately, it's easy to correct. Either do the
"Add" and "Rename" workaround, or:

1) Go to App_Code and add a new Item named "Foo.DataSet1.xsd".

2) Right-click "Foo.DataSet1.xsd" and select "View Code".

3) Go to the opening <xs:element> tag and replace instances of "Foo"
with "DataSet1" in 3 attributes.

 

[Gerry Hickman]

Ah, I think I found the culprit.

There appears to be a bug in the VS2005 xsd template.

This is what I was wondering; is it correct to say that "namespaces" in
general are working in VS2005, but there's a problem with DataSets that
use xsd?

 

[Guest]

Gerry,
That's simply not true.
They are not working as I expect.
But we have found a workaround.
And about the first post you made:

please open up vs 2005 and try this for yourself
mark is absolutely correct, web forms have the subfolder prepended to the
class name in vs2005.
/default.aspx - class = _default
/subfolder/defualt.aspx - class = subfolder_default
/subfolder2/defualt.aspx - class = subfolder2_default

the generated code is NOT inside a new namespace, but is the CLASS NAME that
is built with the syntax: myfolder_myclass.

It seems that there are differences between vb projects and c# projects
templates.

Everyone in this thread are forgotting one of the most important question of
this thread.
In VS2003 (since VS2002), the default behavior was creating NAMESPACES for
each subfolder of the project.

Now everything has been lost. All you posts are confirming that the behavior
of VS2005 has totally changed.

And you must assume that in Class Library projects, Control Library
projects, Windows Form projects, the behavior of building namespaces in
completly different. That's the fact. So my question is simply: WHY?

Compatibility is one of the most important thing that we need to improve
development continuity, but it seems that I'm the only developer of Web
Projects in C# since VS2002, or this requirement it's not furhter important.

 

[Guest]

Thanks Scott.

You've found one.
And what about the code behind generated for WebForms in subfolders? There
Namespaces are not added to.

So when I say that VS2005 has lost namespaces management am I in true?

 

[gerry]

I agree that you are seeing a change in the way that a web project works.
I'm not really sure what the driving purpose behind the change was ( not
that I have looked into it ) , but I disagree with your assertion that the
change is a problem.
You have it fixed in your mind how things should work, and rather than just
accept that the change, you are fighting it and creating a problem where one
really does not exist.
If you have a true need for namespaces because you have a class that will
also be used outside of your web project, then it should be created and
maintained in a separate class library project and referenced by your web
project, then you would have the same namespace behaviour as you did in
2003. And if you have some legit reason for namespaces within the web
project you are free to create them yourself as you please. Sure it means
some extra manual effort, but that is the price you pay for insisting on
having something that isn't required.

since the bug in the dataset template has been exposed , do you have any
other issue that actually relates to a web project being namespace-less ?

Gerry,
That's simply not true.
They are not working as I expect.

No not as you expected, but that doesn't make it wrong.

But we have found a workaround.
And about the first post you made:


the generated code is NOT inside a new namespace, but is the CLASS NAME that
is built with the syntax: myfolder_myclass.

and that is exactly what i said "class = " , I made no mention at all of
namespaces
I was simply addressing the statement that 2 default.aspx's can't have a
class name collision unless you go out of your way to create one.

It seems that there are differences between vb projects and c# projects
templates.

Everyone in this thread are forgotting one of the most important question of
this thread.
In VS2003 (since VS2002), the default behavior was creating NAMESPACES for
each subfolder of the project.

Now everything has been lost. All you posts are confirming that the behavior
of VS2005 has totally changed.

I am failing to see what 'has been lost' ?

And you must assume that in Class Library projects, Control Library
projects, Windows Form projects, the behavior of building namespaces in
completly different. That's the fact. So my question is simply: WHY?

completely different compared to what ?
as far as i can tell these still works exactly the same as they did in 2003

Compatibility is one of the most important thing that we need to improve
development continuity, but it seems that I'm the only developer of Web
Projects in C# since VS2002, or this requirement it's not furhter

important.

correct - multiple namespaces within a single web project are no longer
necessary / important

 

[Christopher Reed]

This is not about how YOU expect it to work; it's about how the designers
expect it to work. You need to change your mindset and be open to these
changes.

 

[Guest]

Gerry,
You are saying that I'm creating a problem that don't exists.
I say that the problem exists, because before changing the behavior of a
project template-driven code generator, a developer Team should consider the
impact with the past.

You must admint that a Default Behavior has changed, and it has changed ONLY
for Web Projects. WITHOUT motivations.

If you don't need namespaces in Web sites, you don't need them either in
Windows Forms, Control... etc. Why there they works as I expect?
So can I open a bug request in Microsoft telling them that Windows Forms
projects namespace management have to be removed?

Or do you think that Microsoft can do what he thinks its better without
considering the approach model proposed in the past (and in the present)?

When you were talking about namespaces in subfolders you were in WRONG. Do
you agree?
Why the need of changing how the Name of classes are built in the Code-Behind?

 

[Guest]

You're right. I was meaning that It doesn't work LIKE ALL the other VS
project types.
You need to change your mindset and accept that the difference exists and
WITHOUT MOTIVATION.

Someone maybe is thinking that I'm one of the anti-microsoft products posters.
I'm speaking as a 12 Years developer in Microsoft Products. I've found a lot
of bugs in this years, and accepted them like all developers.

But I still continue to say this TYPE of changes are inaccetable.

When you say that the change EXISTS and is not a problem, you are admitting
that there was NO REASON to make the change.

And the TEST is that this Behavior persists in the other type of VS projects.

 

[gerry]

Gerry,
You are saying that I'm creating a problem that don't exists.
I say that the problem exists, because before changing the behavior of a
project template-driven code generator, a developer Team should consider the
impact with the past.

I don't agree.
If you want to work the old way, stick with 2003.
Nothing / no-one os forcing you to stay current.

You must admint that a Default Behavior has changed, and it has changed ONLY
for Web Projects. WITHOUT motivations.

So ? Get over it and move on.
I can't speak to motiviation -although I tend to agree with you on this
point, it is still irrelevant.

If you don't need namespaces in Web sites, you don't need them either in
Windows Forms, Control... etc. Why there they works as I expect?
So can I open a bug request in Microsoft telling them that Windows Forms
projects namespace management have to be removed?

again - i can't speak to MS motivation - and again what does it matter ?

Or do you think that Microsoft can do what he thinks its better without
considering the approach model proposed in the past (and in the present)?

well , it is their product - what do you think ?

When you were talking about namespaces in subfolders you were in WRONG. Do
you agree?

No - I never ever mentioned namespaces in subfolders - only class names.

Why the need of changing how the Name of classes are built in the

Code-Behind?

I couldn't say. The more important question is - why do you care ?

 

[Guest]

Thanks fou your opinions.

When I develop a product, and I release a new version of it, my customers
aren't so open. But since now, I won't care of their opinion.

 

[Gerry Hickman]

Hi abunet,

Just to clarify, I'm not the same "gerry" that posted above and below on
this. Where you say "about the first post you made" below, I don't think
it was me that made the post you were quoting...

 

[Christopher Reed]

I know that there are many people who "liked" the project-based development
that came about in VS 2002/2003. I am not one of them. I cannot be happier
with what Microsoft has provided in the form of website "solution", as it
were. More so, not realizing that the subdirectory of App_<whatever> was a
Framework change and not just something for VWD, I am even more impressed
with the efforts made by the ASP.NET team in making these changes available
for web programmers.

Now, let me put my opinions into perspective. Until VS 2005, I have not had
an interest in using Visual Studio as my development. All of my 1.x web
applications were created using a text editor. The only times I would use
VS 2002/2003 would be to test something, like Crystal Reports or web
services, and then modify the generated code to suit my needs. With VS 2005
(I have been primarily using VWD Express just for kicks), Microsoft has
finally created an IDE (besides FPW/VFP) that I'm willing to use. I am
currently developing two small web apps using VWD Express and the experience
has been great. I have chosen to add namespaces, but I realized that
namespaces are not necessary because there should be no risk of having two
or more classes with the same name.

For me, the change to the website approach is perfect for developing
websites. I am currently developing our work standards and frankly, this
approach works with the way I want to approach website development. First,
I start with a website. I will add as many pages (ASPX files) as needed,
along with the associated code-behind files. If I have a class that will be
used by more than one page, then I will put that class within my class file
in the App_Code subdirectory. If I discover that I need that class for
more than one website, then I will put it into a C# class library and
probably put the assembly into the GAC. For the most part, that covers my
development needs.

Web applications are not Windows applications. Under VS 2002/2003, they
were made to look similar; however, the paradigms are far too different to
keep them together. The change to the website approach is one of the best
moves that Microsoft has made in years, in my opinion.

My point is that you disagree with this point of view. However, just
because you disagree with the approach doesn't mean Microsoft did something
wrong. It just means that you're not willing to accept their change in
approach. Nothing more, nothing less.

 

[Gabriel Magaña]

My point is that you disagree with this point of view. However, just

because you disagree with the approach doesn't mean Microsoft did
something wrong. It just means that you're not willing to accept their
change in approach. Nothing more, nothing less.

Looking at this change from an abstract point of view, MS simply moved the
citical data from the project file to the solution file. This is annoying
because solution files used to be no more than groupigs of related projects,
now they hold vital information about the web project.

It used to be that you could have a web site be part of a solution and also
be a part of another solution without a problem. Now you need to make sure
that your critical settings for that web site reside in two different
solutions. Blah! The other half of the critical settings are in the
Web.config file now (ie, references)... Not really big deal.

The problem is that Ms took functionality away from web sites, such as being
able to exclude a file from source control, or from the web site itself.
It's a little annoying that things that used to work do not work anymore.

Maybe it's just me, but I don't see the huge breaktrough anywhere here...
Just some settings reshuffled, some functionality taken away. You can now
pre-compile the whoe web site (hooray!), but it takes forever to do so (the
modify-compile-test process is much slower now).

As for being able to have duplicate class names, it's really a non-issue if
you like to distribute your web app ^H^H^H site by merging all assemblies
with the aspnet_merge.exe utility, duplicate class names break it, so if you
want to distribute less than a zillion .DLLs, you have to have unique names.

All in all, I want more control over my web site/project. I personally
cannot wait for Web Application Projects to mature so I can have more
control over my web site.

 

[Gerry Hickman]

Hi Gabriel,

Looking at this change from an abstract point of view, MS simply moved the
citical data from the project file to the solution file. This is annoying
because solution files used to be no more than groupigs of related projects,
now they hold vital information about the web project.

I don't think this is correct. The solution file is almost redundant in
the context of WebSite's in VS2005, and you don't need a project file at
all with all those horrible paths and references. The WebSite is now
just a collection of files that reside in a folder. Many of the Web
Project settings have now been moved to web.config and personally I
prefer this, as it's just a text file I can edit without worrying about
breaking a project or confusing the Source Control. With a WebSite in
VS2005 you can delete your solution at any time and create a new one if
you like without losing anything of any importance. The new model also
makes it MUCH easier to switch from a FileSystem website running on a
local box to an IIS website running on a FrontPage extended production
server.

It used to be that you could have a web site be part of a solution and also
be a part of another solution without a problem. Now you need to make sure
that your critical settings for that web site reside in two different
solutions. Blah!

I'm pretty sure you can create six solutions all pointing to the same
website if you want.

The problem is that Ms took functionality away from web sites, such as being
able to exclude a file from source control, or from the web site itself.

You can still right-click a file and choose "Exclude from Project" and
it will rename it as *.exclude and show it greyed out in the IDE. If
you're using Source Control you will get an extra warning dialog saying
that you are renaming a file.

The way we run it is to never add the solution to Source Control, just
the website.

Maybe it's just me, but I don't see the huge breaktrough anywhere here...
Just some settings reshuffled, some functionality taken away. You can now
pre-compile the whoe web site (hooray!), but it takes forever to do so (the
modify-compile-test process is much slower now).

You can build just one page if you want, and if you choose "build"
instead of "rebuild" it will do an incremental build so it only builds
the web pages that have changed. With a well designed site using
App_Code etc, it's pretty quick to do incremental.

You are right, however, that in general VS2005 is slower than VS2003.
This is because Microsoft don't know how to write efficient code and
have no incentive to do so - take a look at Vista beta if you don't
believe me - slow and bloated beyond belief.

 

[Gabriel Magaña]

the context of WebSite's in VS2005, and you don't need a project file at
all with all those horrible paths and references.

Horrible? They're vital, they have to go somewhere...

Project settings have now been moved to web.config and personally I prefer
this, as it's just a text file I can edit without worrying about breaking
a project or confusing the Source Control.

How does a project file confuse source control? Plus if you use bad syntax
it's just as easy to break web.config. Project files are also text files,
they just happen to have a different syntax.

VS2005 you can delete your solution at any time and create a new one if
you like without losing anything of any importance.

Well, you be the judge... Solution files are also text files, so open one
up with notepad, and take a look at the data stored about web sites: It's
everything that used to be in the project file that they would have a hard
time justifying putting into web.config, such as project configurations
(debug, release, etc... some source control configs, and a couple other
things. If you have changed any of these things away from their defaults,
it is a pain to reconfigure everything if you switch solution files.

The new model also makes it MUCH easier to switch from a FileSystem website
running on a local box to an IIS website running on a FrontPage extended
production server.

Much easier than what? file system based web sites are new with VS2005 no?

I'm pretty sure you can create six solutions all pointing to the same
website if you want.

Yep, just re-configure each solution. Might be easier to cut and paste the
settings between solution files.

You can still right-click a file and choose "Exclude from Project" and it
will rename it as *.exclude and show it greyed out in the IDE.

It's not the same as "exclude from source control." There are many files
that one might want to keep in a project, but exclude from source control
(images, javascript/images from third party libraries, etc...).

You can build just one page if you want, and if you choose "build" instead
of "rebuild" it will do an incremental build so it only builds the web
pages that have changed. With a well designed site using App_Code etc,
it's pretty quick to do incremental.

I do not trust building to catch all the errors though. Rebuilding the
solution regularly is a good habit to have, it might save hours from chasing
"ghost errors," errors that go away when you do a full rebuild.

This is because Microsoft don't know how to write efficient code and have
no incentive to do so - take a look at Vista beta if you don't believe
me - slow and bloated beyond belief.

It is not fair to expect high performance and stability out of a beta
version... If you were gonna get that, then it would not be a beta, would
it?

Anyway, I just get the sense in general that web sites/applications in
ASP.NET are a couple generations behind in maturity compared to WinForms
applications. MS just came out with this new way of doing things and
managed to piss off many people by oversimplifying the model and removing
features.

You really cannot say, for example, "lose the stupid references to outside
objects" because those references are vital.... You also cannot say "let's
treat web applications as if they were HTML web sites." They are not simple
web sites, if we were able to do what we want to do with Dreamweaver, why
would we be VS users?

Like someone said: Make it as simple as possible, but no simpler.

 

[Guest]

Gabriel,

In general, I agree with your vision.
I know that I haven't many alternatives than accept changes that Microsoft
decide are better for me.

The main thread object was: Disadavantages....
This started when I found that the conversion of a VS2003 project to VS2005
wasn't linear.
When VB programmers made the jump from VS6 to VS.NET, they found many
differences, and some features gone away. But VS6 and VS2002 shared only the
Name.

In my opinion, it's inaccettable to be afraid that in a possible future
VS2006 version, my old projects have been to rewritten. Above all when a new
Product is released every year.

Also I think that if you make a change to the project/solution structure,
you should inform the users about the changes. For what concernes DataSets
and NameSpace, I haven't found any MS document that talks about that. If
anyone have found them, please inform me.

Finally, I'd like to say that I'm also a Visual FoxPro developer. Now VFP is
at version 9, and I since VFP5 (maybe VFP3 but I'm not sure), I dind't had
all this conversion projects, instead I always found many new features.
This demonstrates that a Team that write a good product, can maintain
compatibility and add functionalities, without making them in conflict.

Someone wrote in this thread:
"If you don't like VS2005, just stay in VS2003".

VS2003 can't generate .net 2.0 assemblies, so Microsoft forces me to buy
VS2005 to stay current. .NET tries to eliminate the dll HELL, and I certanly
don't want to start with VS versions HELL.

Web applications are not Windows applications.

I'm sorry for my English, maybe in Italian I could explain better my opinions.

 

[Guest]

Excuse me for the error.

Hi abunet,

Just to clarify, I'm not the same "gerry" that posted above and below on
this. Where you say "about the first post you made" below, I don't think
it was me that made the post you were quoting...

 

[Christopher Reed]

You are not forced to anything. In all of this, you have a choice. One of
the advantages of the .NET Framework as a whole is that you can create
programs independent of Visual Studio, thus for no cost (except for the cost
of Windows). In fact, if you can't program in .NET without Visual Studio,
then I assert that you're not a programmer at all.

Programming is not all of the bells and whistles that the various IDEs that
exist in the development world; it's the code. Any self-respecting
programmer should be able to pull a text editor and start typing. You don't
need Intellisense, you don't need project files, you don't need drag and
drop functionality, etc. While all of these are nice to have and help in
the rapid application development process, if you can't code, the bells and
whistles are more of a distraction.

I had a boss once who loaded VB on his computer and he started messing
around with developing a series of forms for a new application he had in
mind. He was so impressed with himself until he got to a point where all he
had were forms with no code. The minute he started to add code to his
forms, he totally lost interest because he couldn't do it. Up until that
point in time, he thought he was programming in Visual Basic.
Unfortunately, with all the wizards and other tools that IDEs provide, there
are many more "programmers" that shouldn't really exist.

The point that I'm trying to make is that you are looking at the
"disadvantages" of VS 2005 when none of these changes should make any
difference at all to you. If you cannot create a website using a text
editor and the .NET Framework (any version), then you need to step back
first and reevaluate your programming skills. If you are too dependent on
the IDE to accomplish your programming, then, as I stated earlier, you're
not a programmer at all. Additionally, these "disadvantages" should be mere
inconveniences, not show-stoppers in your development progress.