By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,060 Members | 1,878 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,060 IT Pros & Developers. It's quick & easy.

Disadvantages in Visual Studio 2005 (Web sites)

P: n/a
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know
you can still MANUALLY manage them, but not QUICKLY and EASLY. In a
project I can subdivide the App_Code Folder in subfolders, but if I use
the Powerfull "Class View" Window, I'm not very glad to see an infinity
number of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good.
But the need of defining namespaces and grouping classes is indipendent
from the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it
Jan 26 '06 #1
Share this Question
Share on Google+
54 Replies


P: n/a
DWS
Dear Disadvantaged,

I don't often use the new class viewer, it is overpowering like you said.

I'm am however using namespace inside the app_code folder.
My Namespaces do come up in the IDE as expected type assist, imports, etc.


"m.******@dev.it" wrote:
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know
you can still MANUALLY manage them, but not QUICKLY and EASLY. In a
project I can subdivide the App_Code Folder in subfolders, but if I use
the Powerfull "Class View" Window, I'm not very glad to see an infinity
number of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good.
But the need of defining namespaces and grouping classes is indipendent
from the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it

Jan 26 '06 #2

P: n/a
Not familier with VS.NET 2005 but can't you speciify the namespaces in your
classes with the appropriate statement ?

--
Patrice

<m.******@dev.it> a écrit dans le message de
news:ej*************@TK2MSFTNGP11.phx.gbl...
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know
you can still MANUALLY manage them, but not QUICKLY and EASLY. In a
project I can subdivide the App_Code Folder in subfolders, but if I use
the Powerfull "Class View" Window, I'm not very glad to see an infinity
number of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good.
But the need of defining namespaces and grouping classes is indipendent
from the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it

Jan 26 '06 #3

P: n/a
Thanks for your opinion,

Maybe I've not explained very well the problem.
I've already written that I know that I can MANUALLY define namespace, but
the RAD tool doesn't help me in any mode....

These are the real questions:

In the App_Code directory, you can define custom namespaces for .cs files.
But if you add a Dataset (.xsd) how can you define his namespace in visual
studio?

A Web site isn't a collection of classes?

Why a Windows Form Project or a ClassLibrary project manage namespaces in
the right mode?

Why in Visual Studio .Net 2003 I could do it and now not?

Anyone know what does it mean to open hundred of aspx files and write the
namespace?

Thanks

"DWS" wrote:
Dear Disadvantaged,

I don't often use the new class viewer, it is overpowering like you said.

I'm am however using namespace inside the app_code folder.
My Namespaces do come up in the IDE as expected type assist, imports, etc.


"m.******@dev.it" wrote:
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know
you can still MANUALLY manage them, but not QUICKLY and EASLY. In a
project I can subdivide the App_Code Folder in subfolders, but if I use
the Powerfull "Class View" Window, I'm not very glad to see an infinity
number of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good.
But the need of defining namespaces and grouping classes is indipendent
from the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it

Jan 26 '06 #4

P: n/a
Thanks Patrice,

sorry but I'm talking about DISADVANTAGES of Visual Studio, not of the .Net
framework.

"Patrice" wrote:
Not familier with VS.NET 2005 but can't you speciify the namespaces in your
classes with the appropriate statement ?

--
Patrice

<m.******@dev.it> a écrit dans le message de
news:ej*************@TK2MSFTNGP11.phx.gbl...
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know
you can still MANUALLY manage them, but not QUICKLY and EASLY. In a
project I can subdivide the App_Code Folder in subfolders, but if I use
the Powerfull "Class View" Window, I'm not very glad to see an infinity
number of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good.
But the need of defining namespaces and grouping classes is indipendent
from the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it


Jan 26 '06 #5

P: n/a
On Thu, 26 Jan 2006 17:26:54 +0100, m.******@dev.it wrote:

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.


I don't think it's a big issue. 99% of the types in code-behind /
code-beside files are never used outside of the files they are defined
in. Many times they end up in isolated assemblies.

--
Scott
http://www.OdeToCode.com/blogs/scott/
Jan 26 '06 #6

P: n/a
In actuality, if you are developing everything within the same website, then
why do you need a namespace. If you use the App_Code directory for your
website-specific classes and you have multiple ASPX pages (with or without
code-behind), they are all compiled into the same assembly, so where's the
need for a namespace.

Note that I add my namespaces to my website files and I have no problem with
it. It's not a major issue.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

<m.******@dev.it> wrote in message
news:ej*************@TK2MSFTNGP11.phx.gbl...
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know you
can still MANUALLY manage them, but not QUICKLY and EASLY. In a project I
can subdivide the App_Code Folder in subfolders, but if I use the
Powerfull "Class View" Window, I'm not very glad to see an infinity number
of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good. But
the need of defining namespaces and grouping classes is indipendent from
the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG black
hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it

Jan 27 '06 #7

P: n/a
I'm sorry but I don't agree with you.

All the .Net framework is a library subdivided in namespaces.

I'm sorry if you say that you don't need namespaces, you say that .Net
framework doesn't need them.

"Christopher Reed" wrote:
In actuality, if you are developing everything within the same website, then
why do you need a namespace. If you use the App_Code directory for your
website-specific classes and you have multiple ASPX pages (with or without
code-behind), they are all compiled into the same assembly, so where's the
need for a namespace.

Note that I add my namespaces to my website files and I have no problem with
it. It's not a major issue.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

<m.******@dev.it> wrote in message
news:ej*************@TK2MSFTNGP11.phx.gbl...
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know you
can still MANUALLY manage them, but not QUICKLY and EASLY. In a project I
can subdivide the App_Code Folder in subfolders, but if I use the
Powerfull "Class View" Window, I'm not very glad to see an infinity number
of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good. But
the need of defining namespaces and grouping classes is indipendent from
the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG black
hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it


Jan 27 '06 #8

P: n/a
You are confusing the problem.

Namespaces aren't assemblies.

You can define the same namespace for different assemblies.

NAMESPACES are LOGICAL rappresentation of your class library.

And a Web site is an Application with one or more assemblies.

Why the assemblies of a web site cannot be rappresented in namespaces?

"Scott Allen" wrote:
On Thu, 26 Jan 2006 17:26:54 +0100, m.******@dev.it wrote:

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.


I don't think it's a big issue. 99% of the types in code-behind /
code-beside files are never used outside of the files they are defined
in. Many times they end up in isolated assemblies.

--
Scott
http://www.OdeToCode.com/blogs/scott/

Jan 27 '06 #9

P: n/a
A question to everyone tells me that they don't need namespaces:

In your web site. You have 2 folders with 2 default.aspx files, one in each
folder.

If build the web site, you'll get an error, because the compiler finds two
classes with the same name.

The solution is to define a different namespace for each aspx file (or one
of them).

Now, if I have to define ONE namespace for ONE class, a good developer
SHOULD define namespaces for ALL the classes in the projects.

I'll post the question in another thread.

"m.******@dev.it" wrote:
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know
you can still MANUALLY manage them, but not QUICKLY and EASLY. In a
project I can subdivide the App_Code Folder in subfolders, but if I use
the Powerfull "Class View" Window, I'm not very glad to see an infinity
number of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good.
But the need of defining namespaces and grouping classes is indipendent
from the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it

Jan 27 '06 #10

P: n/a
answer me this question please:

In the App_Code directory, you can define custom namespaces for .cs files.
But if you add a Dataset (.xsd) how can you define his namespace in the web
project?
"Christopher Reed" wrote:
In actuality, if you are developing everything within the same website, then
why do you need a namespace. If you use the App_Code directory for your
website-specific classes and you have multiple ASPX pages (with or without
code-behind), they are all compiled into the same assembly, so where's the
need for a namespace.

Note that I add my namespaces to my website files and I have no problem with
it. It's not a major issue.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

<m.******@dev.it> wrote in message
news:ej*************@TK2MSFTNGP11.phx.gbl...
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know you
can still MANUALLY manage them, but not QUICKLY and EASLY. In a project I
can subdivide the App_Code Folder in subfolders, but if I use the
Powerfull "Class View" Window, I'm not very glad to see an infinity number
of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good. But
the need of defining namespaces and grouping classes is indipendent from
the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG black
hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it


Jan 27 '06 #11

P: n/a
On Fri, 27 Jan 2006 00:43:02 -0800, abunet <ab****@ab.it> wrote:
You are confusing the problem.

Namespaces aren't assemblies.

I never said they were.
You can define the same namespace for different assemblies.
NAMESPACES are LOGICAL rappresentation of your class library.

And a Web site is an Application with one or more assemblies.

Why the assemblies of a web site cannot be rappresented in namespaces?

You aren't writing a class library, you are writing a web application.

The ASP.NET runtime will be the only client for all those Page and
UserControl derived types in your web application. The runtime doesn't
need namespaces to figure out what type to use. This is unlike a
developer. Namespaces present logical groupings for developers. I
don't see how there is a BIG black hole when we don't have to write
code like:

using My.WebForms;

Default_aspx form = new Default_aspx();

--
Scott
http://www.OdeToCode.com/blogs/scott/
"Scott Allen" wrote:
On Thu, 26 Jan 2006 17:26:54 +0100, m.******@dev.it wrote:
>
>Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
>black hole.
>


I don't think it's a big issue. 99% of the types in code-behind /
code-beside files are never used outside of the files they are defined
in. Many times they end up in isolated assemblies.

--
Scott
http://www.OdeToCode.com/blogs/scott/


Jan 27 '06 #12

P: n/a
On Fri, 27 Jan 2006 00:38:02 -0800, abunet <ab****@ab.it> wrote:
I'm sorry but I don't agree with you.

All the .Net framework is a library subdivided in namespaces.

I'm sorry if you say that you don't need namespaces, you say that .Net
framework doesn't need them.


The framework does need namespaces. It would be a nightmare to find
classes in a flat hierarchy.

The difference is that the types in the framework have to be found by
human developers. The types in a web application are used only by the
runtime.

There are exceptions of course, like the PreviousPage property for a
cross page postback, but even then I think it's preferable to
represent the other entity using an interface or a base class defined
in a class library (or App_Code) that IS inside a logical namespace
(so it can be found).

Leave the Page and UserControl derived types as islands unto
themselves.

--
Scott
http://www.OdeToCode.com/blogs/scott/
Jan 27 '06 #13

P: n/a
Could you give us the exact error? Perhaps some code? It sounds like
something else is wrong.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Fri, 27 Jan 2006 00:51:02 -0800, abunet <ab****@ab.it> wrote:
A question to everyone tells me that they don't need namespaces:

In your web site. You have 2 folders with 2 default.aspx files, one in each
folder.

If build the web site, you'll get an error, because the compiler finds two
classes with the same name.

The solution is to define a different namespace for each aspx file (or one
of them).

Now, if I have to define ONE namespace for ONE class, a good developer
SHOULD define namespaces for ALL the classes in the projects.

I'll post the question in another thread.

"m.******@dev.it" wrote:
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know
you can still MANUALLY manage them, but not QUICKLY and EASLY. In a
project I can subdivide the App_Code Folder in subfolders, but if I use
the Powerfull "Class View" Window, I'm not very glad to see an infinity
number of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good.
But the need of defining namespaces and grouping classes is indipendent
from the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it


Jan 27 '06 #14

P: n/a
Maybe I'm not explaining very well.

- First of all, if you make a little search on the newsgroup or the web
(keywords: dataset namespace) , you'll find a lot of post with the same
problem.

- Second, You are forgotting that in VS2003, the IDE works in this manner:
if you add a folder to a Web Project, and then an aspx file into it, if you
take a look at the code behind, you will see that the class will have a
namespace with this construct:

namespace myprojectnamespace.myfolder

- To reproduce the problem in VS2005, just add 2 folders to a web site, and
then 2 web forms, each aspx in one folder, and name them default.apsx. You'll
get an error.

- Third do the same with 2 xsd files. In a web site add two folders in the
App_Code. Call each xsd file DataSet1.xsd and put each xsd in a folder.

When you say that you don't need namespaces, I get suprised.
You should only answer this questions:

1) How can you define the namespace of a xsd file in a Web site?
2) Custom Namespaces are built automatically in ClassLibrary and
WindowsForms projects. Why not in Web sites?
3) Why in VS2003 the project namespaces were created automatically and now
not? (compatibility)

Thanks

"Scott Allen" wrote:
Could you give us the exact error? Perhaps some code? It sounds like
something else is wrong.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Fri, 27 Jan 2006 00:51:02 -0800, abunet <ab****@ab.it> wrote:
A question to everyone tells me that they don't need namespaces:

In your web site. You have 2 folders with 2 default.aspx files, one in each
folder.

If build the web site, you'll get an error, because the compiler finds two
classes with the same name.

The solution is to define a different namespace for each aspx file (or one
of them).

Now, if I have to define ONE namespace for ONE class, a good developer
SHOULD define namespaces for ALL the classes in the projects.

I'll post the question in another thread.

"m.******@dev.it" wrote:
In the book:
"Working with Microsoft Visual Studio 2005"
Craig Skibo wrote:
"The power of Visual Studio 2005 lies in its ability to empower users to
build, test, and debug powerful applications quickly and easly."

I don't agree on what concernes ASP .NET Web Sites in VS2005.

All what involves Namespaces in Web sites has been disappeared. I know
you can still MANUALLY manage them, but not QUICKLY and EASLY. In a
project I can subdivide the App_Code Folder in subfolders, but if I use
the Powerfull "Class View" Window, I'm not very glad to see an infinity
number of classes, all placed at the root of the project namespace.

Grouping in namespaces is one of the most powerful skills tha .net gave
us, since 1.0 and not only for .Net Windows Projects.

Someone could reply me that the problem is pre-compilation. I know that
now you can choose how to build your Web site, and this is very good.
But the need of defining namespaces and grouping classes is indipendent
from the way I'll decide to deploy the Web Site.

Is this a "by design" issue?. Or it is a bug? In my opinion is a BIG
black hole.

I'm sorry for this lines, but I'm tired to search for workarounds for an
IDE, abive all when a functionality was already present in the previous
version.

Marco Roello
ma**********@cnrservice.it


Jan 28 '06 #15

P: n/a
"abunet" <ab****@ab.it> wrote in message
news:97**********************************@microsof t.com...
A question to everyone tells me that they don't need namespaces:

In your web site. You have 2 folders with 2 default.aspx files, one in
each
folder.

If build the web site, you'll get an error, because the compiler finds two
classes with the same name.

The solution is to define a different namespace for each aspx file (or one
of them).
That simply isn't true.

<webroot>
/home
default.aspx
<%@ Page language="c#" CodeFile="default.aspx.cs"
Inherits="home_default" %>
default.aspx.cs
public partial class home_default
/welcome
default.aspx
<%@ Page language="c#" CodeFile="default.aspx.cs"
Inherits="welcome_default" %>
default.aspx.cs
public partial class welcome_default
Now, if I have to define ONE namespace for ONE class, a good developer
SHOULD define namespaces for ALL the classes in the projects.


Why? Says who?
Jan 28 '06 #16

P: n/a
Mark,
we are talking about Visual Studio 2005. The RAD Tool.
I know that you can manually define different namespaces.

Please read again all the posts.

"Mark Rae" wrote:
"abunet" <ab****@ab.it> wrote in message
news:97**********************************@microsof t.com...
A question to everyone tells me that they don't need namespaces:

In your web site. You have 2 folders with 2 default.aspx files, one in
each
folder.

If build the web site, you'll get an error, because the compiler finds two
classes with the same name.

The solution is to define a different namespace for each aspx file (or one
of them).


That simply isn't true.

<webroot>
/home
default.aspx
<%@ Page language="c#" CodeFile="default.aspx.cs"
Inherits="home_default" %>
default.aspx.cs
public partial class home_default
/welcome
default.aspx
<%@ Page language="c#" CodeFile="default.aspx.cs"
Inherits="welcome_default" %>
default.aspx.cs
public partial class welcome_default
> Now, if I have to define ONE namespace for ONE class, a good developer
SHOULD define namespaces for ALL the classes in the projects.


Why? Says who?

Jan 28 '06 #17

P: n/a
On Sat, 28 Jan 2006 00:59:26 -0800, abunet <ab****@ab.it> wrote:

- To reproduce the problem in VS2005, just add 2 folders to a web site, and
then 2 web forms, each aspx in one folder, and name them default.apsx. You'll
get an error.


Can you tell us what the specific error message is?

You can't possibly have type name collisions unless there is something
you aren't telling us. The default ASP.NET batch compilation will
generate an assembly for each directory. The assemblies will both have
names like App_Web_*.dll. Even then, the CodeFile classes should have
names like Folder1_Default and Folder2_Default.

Are you using aspnet_merge.exe, perhaps?

--
Scott
http://www.OdeToCode.com/blogs/scott/
Jan 28 '06 #18

P: n/a
That demonstrates that you ask me questions without trying.

Just do what I described in VS2005, (1.5 minutes of work) and you'll get the
error.
I've also opened a Bug Reuest at Microsoft, and they have reproduced the
problem.

Have you got VS2005?

"Scott Allen" wrote:
On Sat, 28 Jan 2006 00:59:26 -0800, abunet <ab****@ab.it> wrote:

- To reproduce the problem in VS2005, just add 2 folders to a web site, and
then 2 web forms, each aspx in one folder, and name them default.apsx. You'll
get an error.


Can you tell us what the specific error message is?

You can't possibly have type name collisions unless there is something
you aren't telling us. The default ASP.NET batch compilation will
generate an assembly for each directory. The assemblies will both have
names like App_Web_*.dll. Even then, the CodeFile classes should have
names like Folder1_Default and Folder2_Default.

Are you using aspnet_merge.exe, perhaps?

--
Scott
http://www.OdeToCode.com/blogs/scott/

Jan 29 '06 #19

P: n/a
On Sun, 29 Jan 2006 01:38:27 -0800, abunet <ab****@ab.it> wrote:
That demonstrates that you ask me questions without trying.

Just do what I described in VS2005, (1.5 minutes of work) and you'll get the
error.
I've also opened a Bug Reuest at Microsoft, and they have reproduced the
problem.

Have you got VS2005?


Yes, VS 2005 RTM.

I have no problems putting two default.aspx web forms into two
different directories. Please elaborate on the problem you see in this
scenario.

I do have a problem putting two .xsd files with the same name into two
sub-directories of App_Code. You can put the generated DataSets into
different namespaces by:

1. Using a file naming convention.

2. Use a class library instead of App_Code.

As an example of #1, name one file Foo.DataSet1.xsd and the other
Bar.DataSet1.xsd. The runtime will generate a DataSet1 class in a Foo
namespace, and a DataSet1 class in a Bar namespace.

--
Scott
http://www.OdeToCode.com/blogs/scott/

Jan 30 '06 #20

P: n/a
Thanks for your test, but it still doesn't work.

"Scott Allen" wrote:
1. Using a file naming convention.
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("Sy stem.Data.Design.TypedDataSetGenerator", "2.0.0.0")]
[Serializable()]
[System.ComponentModel.DesignerCategoryAttribute("c ode")]
[System.ComponentModel.ToolboxItem(true)]

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

"Scott Allen" wrote: 2. Use a class library instead of App_Code.
2. This confirms that Vs2005 Web sites don't support namespaces

"Scott Allen" wrote:
On Sun, 29 Jan 2006 01:38:27 -0800, abunet <ab****@ab.it> wrote:
That demonstrates that you ask me questions without trying.

Just do what I described in VS2005, (1.5 minutes of work) and you'll get the
error.
I've also opened a Bug Reuest at Microsoft, and they have reproduced the
problem.

Have you got VS2005?


Yes, VS 2005 RTM.

I have no problems putting two default.aspx web forms into two
different directories. Please elaborate on the problem you see in this
scenario.

I do have a problem putting two .xsd files with the same name into two
sub-directories of App_Code. You can put the generated DataSets into
different namespaces by:

1. Using a file naming convention.

2. Use a class library instead of App_Code.

As an example of #1, name one file Foo.DataSet1.xsd and the other
Bar.DataSet1.xsd. The runtime will generate a DataSet1 class in a Foo
namespace, and a DataSet1 class in a Bar namespace.

--
Scott
http://www.OdeToCode.com/blogs/scott/

Jan 30 '06 #21

P: n/a
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
"abunet" <ab****@ab.it> wrote in message
news:84**********************************@microsof t.com...
Mark,
we are talking about Visual Studio 2005. The RAD Tool.
I know that you can manually define different namespaces.

Please read again all the posts.

"Mark Rae" wrote:
"abunet" <ab****@ab.it> wrote in message
news:97**********************************@microsof t.com...
A question to everyone tells me that they don't need namespaces:

In your web site. You have 2 folders with 2 default.aspx files, one in
each
folder.

If build the web site, you'll get an error, because the compiler finds two classes with the same name.

The solution is to define a different namespace for each aspx file (or one of them).


That simply isn't true.

<webroot>
/home
default.aspx
<%@ Page language="c#" CodeFile="default.aspx.cs"
Inherits="home_default" %>
default.aspx.cs
public partial class home_default
/welcome
default.aspx
<%@ Page language="c#" CodeFile="default.aspx.cs"
Inherits="welcome_default" %>
default.aspx.cs
public partial class welcome_default
> Now, if I have to define ONE namespace for ONE class, a good developer SHOULD define namespaces for ALL the classes in the projects.


Why? Says who?

Jan 30 '06 #22

P: n/a
On Mon, 30 Jan 2006 02:59:12 -0800, abunet <ab****@ab.it> wrote:
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.

--
Scott
http://www.OdeToCode.com/blogs/scott/
Jan 30 '06 #23

P: n/a
Scott Allen wrote:
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?

--
Gerry Hickman (London UK)
Jan 31 '06 #24

P: n/a
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.

"Gerry Hickman" wrote:
Scott Allen wrote:
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?

--
Gerry Hickman (London UK)

Jan 31 '06 #25

P: n/a
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?

"Scott Allen" wrote:
On Mon, 30 Jan 2006 02:59:12 -0800, abunet <ab****@ab.it> wrote:
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.

--
Scott
http://www.OdeToCode.com/blogs/scott/

Jan 31 '06 #26

P: n/a
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 ?
"abunet" <ab****@ab.it> wrote in message
news:99**********************************@microsof t.com...
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:
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.
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

"Gerry Hickman" wrote:
Scott Allen wrote:
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?

--
Gerry Hickman (London UK)

Jan 31 '06 #27

P: n/a
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.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

"abunet" <ab****@ab.it> wrote in message
news:99**********************************@microsof t.com...
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.

"Gerry Hickman" wrote:
Scott Allen wrote:
> 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?

--
Gerry Hickman (London UK)

Jan 31 '06 #28

P: n/a
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?

"gerry" wrote:
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 ?
"abunet" <ab****@ab.it> wrote in message
news:99**********************************@microsof t.com...
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:
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.


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

"Gerry Hickman" wrote:
Scott Allen wrote:

> 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?

--
Gerry Hickman (London UK)


Jan 31 '06 #29

P: n/a
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.

"Christopher Reed" wrote:
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.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

"abunet" <ab****@ab.it> wrote in message
news:99**********************************@microsof t.com...
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.

"Gerry Hickman" wrote:
Scott Allen wrote:

> 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?

--
Gerry Hickman (London UK)


Jan 31 '06 #30

P: n/a

"abunet" <ab****@ab.it> wrote in message
news:17**********************************@microsof t.com...
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 ?

"gerry" wrote:
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 ?

"abunet" <ab****@ab.it> wrote in message
news:99**********************************@microsof t.com...
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:

> 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.


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

"Gerry Hickman" wrote:

> Scott Allen wrote:
>
> > 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?
>
> --
> Gerry Hickman (London UK)
>


Jan 31 '06 #31

P: n/a
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" wrote:

"abunet" <ab****@ab.it> wrote in message
news:17**********************************@microsof t.com...
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 ?

"gerry" wrote:
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 ?

"abunet" <ab****@ab.it> wrote in message
news:99**********************************@microsof t.com...
> 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:
>
> > 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.

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

>
> "Gerry Hickman" wrote:
>
> > Scott Allen wrote:
> >
> > > 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?
> >
> > --
> > Gerry Hickman (London UK)
> >


Jan 31 '06 #32

P: n/a
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...

abunet wrote:
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:


--
Gerry Hickman (London UK)
Feb 1 '06 #33

P: n/a
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.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

"abunet" <ab****@ab.it> wrote in message
news:31**********************************@microsof t.com...
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.

"Christopher Reed" wrote:
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.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

Feb 1 '06 #34

P: n/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.
Feb 1 '06 #35

P: n/a
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.

--
Gerry Hickman (London UK)
Feb 2 '06 #36

P: n/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.
Feb 2 '06 #37

P: n/a
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.

Christopher wrote:
Web applications are not Windows applications.
I'm sorry for my English, maybe in Italian I could explain better my opinions.

"Gabriel Magaña" wrote:
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.

Feb 2 '06 #38

P: n/a
Excuse me for the error.

"Gerry Hickman" wrote:
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...

abunet wrote:
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:


--
Gerry Hickman (London UK)

Feb 2 '06 #39

P: n/a
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.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

"abunet" <ab****@ab.it> wrote in message
news:99**********************************@microsof t.com...
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.

Christopher wrote:
Web applications are not Windows applications.


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

"Gabriel Magaña" wrote:
> 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.

Feb 2 '06 #40

P: n/a
abunet wrote:
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.


In my opinion, it is Microsoft's sole purpose to release a product, then
define that as the industry standard and expect everyone to follow it,
then release the next version of the product, standards be damned, and
then expect everyone to change to their new model that is never
backwards compatible.
Feb 2 '06 #41

P: n/a
Christopher Reed wrote:
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.


Their CONSTANT changing of approaches. MS completely alienates their
existing base of users with each release; always concerned about
attracting new users with 'new and better ways'.
Feb 2 '06 #42

P: n/a
Christopher Reed wrote:
You are not forced to anything. In all of this, you have a choice.


No you don't, you lost the option to choose when MS decided to tie the
development environment to the framework.

Bad for choice, great for MS.
Feb 2 '06 #43

P: n/a
Peter, you're the first person that have understood the meaning of this
thread. It make me less afraid to be the only one that belives in
compatibility.

Peter Franks ha scritto:
Christopher Reed wrote:
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.

Their CONSTANT changing of approaches. MS completely alienates their
existing base of users with each release; always concerned about
attracting new users with 'new and better ways'.

Feb 2 '06 #44

P: n/a
Christopher,
Thanks for the post, but I can't understand your answer.
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
False. You're forgetting the time spent to find a solution for the
disadvantage, or the time spent to understand the changes. And time is cost.
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. I've never said that I can't.
Additionally, these "disadvantages" should be mere
inconveniences, not show-stoppers in your development progress. I've never said I've stopped something. When I started posting my question,
I'd already had found a workaround.

In the last post, I only wanted to specify that there are other products
(like VFP) that in several years didn't confuse their customers at every
upgrade of version.
So it demonstrates that is possible. Not more, not Less.

"Christopher Reed" wrote:
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.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

"abunet" <ab****@ab.it> wrote in message
news:99**********************************@microsof t.com...
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.

Christopher wrote:
Web applications are not Windows applications.


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

"Gabriel Magaña" wrote:

> 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.


Feb 2 '06 #45

P: n/a
On Mon, 30 Jan 2006 23:54:09 +0000, Gerry Hickman
<ge********@yahoo.co.uk> wrote:
Scott Allen wrote:
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?


Yes, I'd say that is correct.

--
Scott
http://www.OdeToCode.com/blogs/scott/
Feb 2 '06 #46

P: n/a
On Tue, 31 Jan 2006 01:16:27 -0800, abunet <ab****@ab.it> wrote:
Thanks Scott.

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


Sorry about that - dropped out of civilization for a bit.

I don't think putting WebForm classes into namespaces is entirely
useful. In fact, I've only seen trouble result when coupling too
closely to the code-behind class for a web form. It's best if they are
out on there own and remain anonymous.

Nevertheless, if you want to use the same model as 2003 in 2005, then
you'll want to use Web Application Projects [1]. Although it is
missing some features currently, it will be a full blown supported
package by MS.

[1] http://webproject.scottgu.com/

--
Scott
http://www.OdeToCode.com/blogs/scott/
Feb 2 '06 #47

P: n/a
On Thu, 02 Feb 2006 07:50:43 -0800, Peter Franks <no**@none.com>
wrote:
Christopher Reed wrote:
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.


Their CONSTANT changing of approaches. MS completely alienates their
existing base of users with each release; always concerned about
attracting new users with 'new and better ways'.


MS has essentially admitted to a mistake [1]. Although many people
like the new model, migration has proved difficult. Thus, "Web
Application Projects" [2] were born.

[1] http://weblogs.asp.net/scottgu/archi...16/433374.aspx

[2] http://webproject.scottgu.com/

--
Scott
http://www.OdeToCode.com/blogs/scott/
Feb 2 '06 #48

P: n/a
Peter Franks wrote:
Their CONSTANT changing of approaches. MS completely alienates their
existing base of users with each release; always concerned about
attracting new users with 'new and better ways'.


Personally I agree with this, although it's important to separate
deliberate "forced change for political reasons" and genuine
technological advantage where you have to move from an earlier model.

I think we've seen far too much hype and politics recently and very
little technical innovation. Vista is a case in point.

--
Gerry Hickman (London UK)
Feb 2 '06 #49

P: n/a
abunet wrote:
Peter, you're the first person that have understood the meaning of this
thread. It make me less afraid to be the only one that belives in
compatibility.


Thing is; their model is great for home user types who dabble, but it's
a headache for people who have to do real work. Complex systems and web
applications have run on UNIX/LINUX for years with hardly a reboot in
sight and are easy to migrate to new servers, but Microsoft's software
needs constant attention and patching. It's great if you're a lone user
with Admin rights and do everything in the GUI, but not so good when you
want to maintain it on hundreds of machines at a remote location.

--
Gerry Hickman (London UK)
Feb 2 '06 #50

54 Replies

This discussion thread is closed

Replies have been disabled for this discussion.