A fairly new person at ASP.

Discussion in 'ASP .Net' started by David, Jul 22, 2006.

  1. David

    David Guest

    Hey,

    I'm a fairly new person at ASP, and MS technologies kinda in general.
    I've been a big fan of PHP/MySQL, and unix environments for awhile. I
    used to do VC++ and VB with VS6, and have for the most part no
    experience at all with the .net framework.

    To expand my knowledge, I'm hoping to get into ASP some - and to learn
    VB.net and C# as well, to program in ASP. I was hoping that I could
    ask a few questions that I had kinda right off, that I couldn't really
    find the answer to in my ASP.net 2.0 Unleashed book, that I recently
    bought.

    The first question is about editors and compiling. Coming from a
    unixtypeish background, I enjoy using more unix editors than windows
    ones. This is mostly just personal preference, but is there ways of
    doing ASP.net 2.0 pages and compile them from the command line (From
    what I understand asp pages are compiled into a microsoft intermediate
    language). I have VS.net, though, 2002 I think it was from the
    university but I haven't really used it much.

    The second question is about databases. I have experience mostly with
    MySQL overall, and have it already setup on my mac. I'm running
    windows through parallels workstation, which emulates a machine for the
    most part. I was hoping not to increase the overhead of my setup if
    possible - are there classes or anything available for connecting to a
    MySQL database, over an SQL server one? I want to get experience in
    both of course, but at this point I just want to take more baby steps
    kinda.

    Thanks for any help anyone can give on these questions, I really appreciate it.

    -David
     
    David, Jul 22, 2006
    #1
    1. Advertising

  2. David

    Scott M. Guest

    > The first question is about editors and compiling. Coming from a
    > unixtypeish background, I enjoy using more unix editors than windows ones.
    > This is mostly just personal preference, but is there ways of doing
    > ASP.net 2.0 pages and compile them from the command line (From what I
    > understand asp pages are compiled into a microsoft intermediate language).
    > I have VS.net, though, 2002 I think it was from the university but I
    > haven't really used it much.


    You must have the .NET Framework on any machine where you will develop or
    run .NET applications. The Framework comes with command line compilers for
    each of the .NET languages, so yes, you could use any editor you wish and
    manually compile.

    > The second question is about databases. I have experience mostly with
    > MySQL overall, and have it already setup on my mac. I'm running windows
    > through parallels workstation, which emulates a machine for the most part.
    > I was hoping not to increase the overhead of my setup if possible - are
    > there classes or anything available for connecting to a MySQL database,
    > over an SQL server one? I want to get experience in both of course, but
    > at this point I just want to take more baby steps kinda.


    The are ODBC and OLEDB classes to access any ODBC or OLEDB compliant data
    source. There are also dedicated SQL data classes.


    One other minor note. To distinguish from the old ASP (now called "Classic
    ASP" by many), the ASP that you work with in .NET is referred to as ASP.NET,
    not ASP. Some folks will get confused if you mean .NET, but just say ASP
    and not ASP.NET.
     
    Scott M., Jul 22, 2006
    #2
    1. Advertising

  3. U¿ytkownik "Scott M." <> napisa³ w wiadomo¶ci
    news:...
    >> The first question is about editors and compiling. Coming from a
    >> unixtypeish background, I enjoy using more unix editors than windows
    >> ones. This is mostly just personal preference, but is there ways of doing
    >> ASP.net 2.0 pages and compile them from the command line (From what I
    >> understand asp pages are compiled into a microsoft intermediate
    >> language). I have VS.net, though, 2002 I think it was from the university
    >> but I haven't really used it much.

    >
    > You must have the .NET Framework on any machine where you will develop or
    > run .NET applications. The Framework comes with command line compilers
    > for each of the .NET languages, so yes, you could use any editor you wish
    > and manually compile.


    I agree up to a point. In fact you do not need .Net Framework installed on
    your machine
    until you write script files. It is possible to write script file on Unix
    system,
    transfer it onto IIS web server and run. Pre-compiled dll files are not
    required
    in most cases, so you do not need any .net compiler on workstation.

    Of course there is also .Net Framework available on Unix systems (the most
    known
    on Free BSD).


    --
    JS
    BRE Bank Dev Team, Poland
     
    Jacek Stawicki, Jul 22, 2006
    #3
  4. David

    Mark Rae Guest

    Mark Rae, Jul 22, 2006
    #4
  5. David

    Scott M. Guest

    > I agree up to a point. In fact you do not need .Net Framework installed on
    > your machine
    > until you write script files. It is possible to write script file on Unix
    > system,
    > transfer it onto IIS web server and run. Pre-compiled dll files are not
    > required
    > in most cases, so you do not need any .net compiler on workstation.


    But, let's be realistic. Without the .NET Framework, you might as well just
    stick to Classic ASP, since you won't get to use any of the .NET classes or
    work with compiled code.

    While it is *possible* to create .aspx files and have them run without the
    Framework, it is not realistic.
     
    Scott M., Jul 22, 2006
    #5
  6. David

    Scott M. Guest

    >> There are also dedicated SQL data classes.
    >
    > Yes, but only because the people who make SQL Server also make the .NET
    > Framework. :)


    What's your point?

    > There are loads of native .NET data providers for other databases
    > available


    Well, they really aren't native, since they aren't included natively with
    the .NET Framework. The Framework comes with the following *native*
    providers

    ODBC, OLE DB, Oracle, SQL
     
    Scott M., Jul 22, 2006
    #6
  7. > Well, they really aren't native, since they aren't included natively with
    > the .NET Framework. The Framework comes with the following *native*
    > providers
    >
    > ODBC, OLE DB, Oracle, SQL


    Incorrect. A "native provider" is a provider that works directly with the
    database software, rather than via OLE DB OR ODBC, both of which are
    intermediate technologies that provide a single unified programming API for
    many database types. In fact, ODBC itself is a wrapper for OLE DB, which is
    a low-level intermediate technology. The Hierarchy is something like this:

    System.Data.ODBC
    ****************
    |
    ODBC (with specific database driver)
    |
    OLE DB
    |
    OLE DB-compliant Database

    System.Data.OleDb
    ***************
    |
    OLE DB
    |
    OLE DB-compliant Database


    When a native .Net data provider is used, the connection to the database is
    immediate:

    System.Data.SqlClient
    *****************
    |
    SQL Server

    System.Data.OracleClient
    ********************
    |
    Oracle

    Therefore, a native provider is more efficient than either OLE DB or ODBC.
    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    Professional Chicken Salad Alchemist

    What You Seek Is What You Get.


    "Scott M." <> wrote in message
    news:...
    >>> There are also dedicated SQL data classes.

    >>
    >> Yes, but only because the people who make SQL Server also make the .NET
    >> Framework. :)

    >
    > What's your point?
    >
    >> There are loads of native .NET data providers for other databases
    >> available

    >
    > Well, they really aren't native, since they aren't included natively with
    > the .NET Framework. The Framework comes with the following *native*
    > providers
    >
    > ODBC, OLE DB, Oracle, SQL
    >
     
    Kevin Spencer, Jul 23, 2006
    #7
  8. David

    Scott M. Guest

    Agreed. My use of the term *Native* was referring to *built-into* the
    framework.


    "Kevin Spencer" <> wrote in message
    news:...
    >> Well, they really aren't native, since they aren't included natively with
    >> the .NET Framework. The Framework comes with the following *native*
    >> providers
    >>
    >> ODBC, OLE DB, Oracle, SQL

    >
    > Incorrect. A "native provider" is a provider that works directly with the
    > database software, rather than via OLE DB OR ODBC, both of which are
    > intermediate technologies that provide a single unified programming API
    > for many database types. In fact, ODBC itself is a wrapper for OLE DB,
    > which is a low-level intermediate technology. The Hierarchy is something
    > like this:
    >
    > System.Data.ODBC
    > ****************
    > |
    > ODBC (with specific database driver)
    > |
    > OLE DB
    > |
    > OLE DB-compliant Database
    >
    > System.Data.OleDb
    > ***************
    > |
    > OLE DB
    > |
    > OLE DB-compliant Database
    >
    >
    > When a native .Net data provider is used, the connection to the database
    > is immediate:
    >
    > System.Data.SqlClient
    > *****************
    > |
    > SQL Server
    >
    > System.Data.OracleClient
    > ********************
    > |
    > Oracle
    >
    > Therefore, a native provider is more efficient than either OLE DB or ODBC.
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > Professional Chicken Salad Alchemist
    >
    > What You Seek Is What You Get.
    >
    >
    > "Scott M." <> wrote in message
    > news:...
    >>>> There are also dedicated SQL data classes.
    >>>
    >>> Yes, but only because the people who make SQL Server also make the .NET
    >>> Framework. :)

    >>
    >> What's your point?
    >>
    >>> There are loads of native .NET data providers for other databases
    >>> available

    >>
    >> Well, they really aren't native, since they aren't included natively with
    >> the .NET Framework. The Framework comes with the following *native*
    >> providers
    >>
    >> ODBC, OLE DB, Oracle, SQL
    >>

    >
    >
     
    Scott M., Jul 23, 2006
    #8
  9. David

    Mark Rae Guest

    "Scott M." <> wrote in message
    news:...

    > Agreed. My use of the term *Native* was referring to *built-into* the
    > framework.


    I can't help that...

    v1.0 didn't have either "native" or "built-in" support for ODBC - instead,
    it was available only as an add-on.
     
    Mark Rae, Jul 23, 2006
    #9
  10. David

    Scott M. Guest

    The ODBC Namespace and the classes therein have been part of the .NET
    Framework since the beginning. Using it did not require any add-ins.


    "Mark Rae" <> wrote in message
    news:...
    > "Scott M." <> wrote in message
    > news:...
    >
    >> Agreed. My use of the term *Native* was referring to *built-into* the
    >> framework.

    >
    > I can't help that...
    >
    > v1.0 didn't have either "native" or "built-in" support for ODBC - instead,
    > it was available only as an add-on.
    >
     
    Scott M., Jul 23, 2006
    #10
  11. David

    Mark Rae Guest

    "Scott M." <> wrote in message
    news:%...

    > The ODBC Namespace and the classes therein have been part of the .NET
    > Framework since the beginning.


    Er...you sure...?

    >Using it did not require any add-ins.


    Apart, obviously, from the one you had to download from the Microsoft site
    and install separately...
    http://www.microsoft.com/downloads/...27-1017-4f33-a062-d165078e32b1&displaylang=en

    And then set about configuring machine.config manually, etc...
     
    Mark Rae, Jul 23, 2006
    #11
  12. David

    David Thole Guest

    On 2006-07-22 17:57:30 -0500, "Scott M." <> said:

    >> I agree up to a point. In fact you do not need .Net Framework installed
    >> on your machine
    >> until you write script files. It is possible to write script file on
    >> Unix system,
    >> transfer it onto IIS web server and run. Pre-compiled dll files are not
    >> required
    >> in most cases, so you do not need any .net compiler on workstation.

    >
    > But, let's be realistic. Without the .NET Framework, you might as well
    > just stick to Classic ASP, since you won't get to use any of the .NET
    > classes or work with compiled code.
    >
    > While it is *possible* to create .aspx files and have them run without
    > the Framework, it is not realistic.


    Thanks to both of you for your help in answering this question. In the
    end, I'll probably just create a mount location to that directory, and
    edit files that way, then run them. To my understanding that should
    work, even if the debugging doesn't work fully.
     
    David Thole, Jul 23, 2006
    #12
  13. David

    David Thole Guest

    On 2006-07-23 13:31:58 -0500, "Scott M." <> said:

    > The ODBC Namespace and the classes therein have been part of the .NET
    > Framework since the beginning. Using it did not require any add-ins.
    >
    >
    > "Mark Rae" <> wrote in message
    > news:...
    >> "Scott M." <> wrote in message
    >> news:...
    >>
    >>> Agreed. My use of the term *Native* was referring to *built-into* the
    >>> framework.

    >>
    >> I can't help that...
    >>
    >> v1.0 didn't have either "native" or "built-in" support for ODBC -
    >> instead, it was available only as an add-on.


    Thanks to all of you for the help on this, and the answers to my
    questions. It's a little over my head right now, hopefully within a
    few months I'll understand ASP better. I got ASP .net 2.0 unleashed
    yesterday, and it's a pretty good book - a bit over my head since I
    dont' know VB.net or C#.net at all at this point. I used to use VB6
    and VC++ 6, but not this.

    Thanks again,

    David
     
    David Thole, Jul 23, 2006
    #13
  14. David

    Scott M. Guest

    If you look at the publish date of the add-in you refer to, you will see
    that it pre-dates the public release of VS.NET 2002.

    Installing VS.NET 2002 gives you the 1.0 Framework and the ODBC provider is
    available immediately.

    "Mark Rae" <> wrote in message
    news:...
    > "Scott M." <> wrote in message
    > news:%...
    >
    >> The ODBC Namespace and the classes therein have been part of the .NET
    >> Framework since the beginning.

    >
    > Er...you sure...?
    >
    >>Using it did not require any add-ins.

    >
    > Apart, obviously, from the one you had to download from the Microsoft site
    > and install separately...
    > http://www.microsoft.com/downloads/...27-1017-4f33-a062-d165078e32b1&displaylang=en
    >
    > And then set about configuring machine.config manually, etc...
    >
     
    Scott M., Jul 23, 2006
    #14
  15. David

    Mark Rae Guest

    "Scott M." <> wrote in message
    news:ulq%...

    > If you look at the publish date of the add-in you refer to, you will see
    > that it pre-dates the public release of VS.NET 2002.


    LOL!

    > Installing VS.NET 2002 gives you the 1.0 Framework and the ODBC provider
    > is available immediately.


    <rolls eyes>

    http://support.microsoft.com/default.aspx?scid=kb;en-us;310985

    Read the paragraph which begins "The ODBC .NET Data Provider is an add-on
    component to the Microsoft .NET Framework..." very slowly and carefully, one
    word at a time...

    Here's another one: http://www.akadia.com/services/dotnet_dbaccess.html

    Scroll down to point 6, and read aloud the paragraph beginning "Unlike the
    two other .NET providers, the Odbc provider is not shipped with the .NET
    Framework..."
     
    Mark Rae, Jul 23, 2006
    #15
  16. David

    Scott M. Guest

    I have read each of the articles, but neither addresses the point that we're
    talking about the status of the Framework during the pre-release period.


    "Mark Rae" <> wrote in message
    news:...
    > "Scott M." <> wrote in message
    > news:ulq%...
    >
    >> If you look at the publish date of the add-in you refer to, you will see
    >> that it pre-dates the public release of VS.NET 2002.

    >
    > LOL!
    >
    >> Installing VS.NET 2002 gives you the 1.0 Framework and the ODBC provider
    >> is available immediately.

    >
    > <rolls eyes>
    >
    > http://support.microsoft.com/default.aspx?scid=kb;en-us;310985
    >
    > Read the paragraph which begins "The ODBC .NET Data Provider is an add-on
    > component to the Microsoft .NET Framework..." very slowly and carefully,
    > one word at a time...
    >
    > Here's another one: http://www.akadia.com/services/dotnet_dbaccess.html
    >
    > Scroll down to point 6, and read aloud the paragraph beginning "Unlike the
    > two other .NET providers, the Odbc provider is not shipped with the .NET
    > Framework..."
    >
     
    Scott M., Jul 23, 2006
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    13
    Views:
    763
    Chaddy2222
    Apr 11, 2006
  2. Replies:
    5
    Views:
    418
    JEDIDIAH
    Jun 20, 2006
  3. russzee
    Replies:
    2
    Views:
    357
    russzee
    Oct 25, 2006
  4. guest

    new window["person"]

    guest, Jul 27, 2006, in forum: Javascript
    Replies:
    1
    Views:
    167
    Vincent van Beveren
    Jul 28, 2006
  5. ethanhunt22
    Replies:
    0
    Views:
    453
    ethanhunt22
    Jun 10, 2012
Loading...

Share This Page