vb.net running in debug mode vs. running the executable

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Brad Pears

    vb.net running in debug mode vs. running the executable

    I have a vb.net 2005 project and have made a lot of modifications to it. The
    project runs fine in debug mode. Now I want to implement it and first I am
    running the executable on my machine to make sure it runs properly...
    However, when I run it locally as an executable, I get no end to run time
    errors - things like conversions from type string to integer etc...etc....
    There's seems to be a billion problems all of a sudden.

    I have option strict turned OFF in my development environment. Is it
    enforcing all of these errors that would normally have been generated with
    option strict ON when running as an executable? Is there a way to get around
    it at all? I don;t understand why it runs perfectly fine in dev but bombs
    out in a big way when running as an executable...

    Thanks,

    Brad


  • rowe_newsgroups

    #2
    Re: vb.net running in debug mode vs. running the executable

    On May 22, 5:39 pm, "Brad Pears" <br...@truenort hloghomes.comwr ote:
    I have a vb.net 2005 project and have made a lot of modifications to it. The
    project runs fine in debug mode. Now I want to implement it and first I am
    running the executable on my machine to make sure it runs properly...
    However, when I run it locally as an executable, I get no end to run time
    errors - things like conversions from type string to integer etc...etc....
    There's seems to be a billion problems all of a sudden.
    >
    I have option strict turned OFF in my development environment. Is it
    enforcing all of these errors that would normally have been generated with
    option strict ON when running as an executable? Is there a way to get around
    it at all? I don;t understand why it runs perfectly fine in dev but bombs
    out in a big way when running as an executable...
    >
    Thanks,
    >
    Brad
    Why do you have Option Strict turned Off? In my book that is a huge no-
    no. I'm not sure why they don't blow up during development, but you
    should turn on Option Strict and fix them.

    Thanks,

    Seth Rowe [MVP]

    Comment

    • Brad Pears

      #3
      Re: vb.net running in debug mode vs. running the executable

      Yes, I think you are right - I will do that from now on.... They really
      shouldn't even give you that option really...

      Thanks, Brad

      "rowe_newsgroup s" <rowe_email@yah oo.comwrote in message
      news:39f4e0a2-f792-4cbf-be8f-50e2fc57991f@a7 0g2000hsh.googl egroups.com...
      On May 22, 5:39 pm, "Brad Pears" <br...@truenort hloghomes.comwr ote:
      >I have a vb.net 2005 project and have made a lot of modifications to it.
      >The
      >project runs fine in debug mode. Now I want to implement it and first I
      >am
      >running the executable on my machine to make sure it runs properly...
      >However, when I run it locally as an executable, I get no end to run time
      >errors - things like conversions from type string to integer
      >etc...etc... .
      >There's seems to be a billion problems all of a sudden.
      >>
      >I have option strict turned OFF in my development environment. Is it
      >enforcing all of these errors that would normally have been generated
      >with
      >option strict ON when running as an executable? Is there a way to get
      >around
      >it at all? I don;t understand why it runs perfectly fine in dev but bombs
      >out in a big way when running as an executable...
      >>
      >Thanks,
      >>
      >Brad
      >
      Why do you have Option Strict turned Off? In my book that is a huge no-
      no. I'm not sure why they don't blow up during development, but you
      should turn on Option Strict and fix them.
      >
      Thanks,
      >
      Seth Rowe [MVP]

      Comment

      • Patrice

        #4
        Re: vb.net running in debug mode vs. running the executable

        It shouldn't be the difference all things being equals. If I remember the
        IDE have an otpion to hide exceptions.

        Also if you done your appl to continue whatever happens you'll have loads of
        errors if something goes wrong but the first one is likely the more
        signigifant (but example if data can't be loaded, you can then run in a fiar
        amount of subsequent errors).

        Your best bet would be investigate the first error you get. Optino strict o
        is a good idea but it shouldn"t make a difference all things being equal
        (basically it help to makes code that won"t contains those errors but if it
        is off there i not reason you can run the code in debug mdoe with no error
        and have loads of error when running the EXE file).

        --
        Patrice

        "Brad Pears" <bradp@truenort hloghomes.coma écrit dans le message de groupe
        de discussion : eoQGHRFvIHA.484 8@TK2MSFTNGP05. phx.gbl...
        I have a vb.net 2005 project and have made a lot of modifications to it.
        The project runs fine in debug mode. Now I want to implement it and first
        I am running the executable on my machine to make sure it runs properly...
        However, when I run it locally as an executable, I get no end to run time
        errors - things like conversions from type string to integer etc...etc....
        There's seems to be a billion problems all of a sudden.
        >
        I have option strict turned OFF in my development environment. Is it
        enforcing all of these errors that would normally have been generated with
        option strict ON when running as an executable? Is there a way to get
        around it at all? I don;t understand why it runs perfectly fine in dev but
        bombs out in a big way when running as an executable...
        >
        Thanks,
        >
        Brad
        >

        Comment

        • Brad Pears

          #5
          Re: vb.net running in debug mode vs. running the executable

          Thanks for your help!!!


          "Patrice" <http://www.chez.com/scribe/wrote in message
          news:BC999535-10C3-478F-9C22-CCCCD0D6C219@mi crosoft.com...
          It shouldn't be the difference all things being equals. If I remember the
          IDE have an otpion to hide exceptions.
          >
          Also if you done your appl to continue whatever happens you'll have loads
          of errors if something goes wrong but the first one is likely the more
          signigifant (but example if data can't be loaded, you can then run in a
          fiar amount of subsequent errors).
          >
          Your best bet would be investigate the first error you get. Optino strict
          o is a good idea but it shouldn"t make a difference all things being equal
          (basically it help to makes code that won"t contains those errors but if
          it is off there i not reason you can run the code in debug mdoe with no
          error and have loads of error when running the EXE file).
          >
          --
          Patrice
          >
          "Brad Pears" <bradp@truenort hloghomes.coma écrit dans le message de
          groupe de discussion : eoQGHRFvIHA.484 8@TK2MSFTNGP05. phx.gbl...
          >I have a vb.net 2005 project and have made a lot of modifications to it.
          >The project runs fine in debug mode. Now I want to implement it and first
          >I am running the executable on my machine to make sure it runs
          >properly... However, when I run it locally as an executable, I get no end
          >to run time errors - things like conversions from type string to integer
          >etc...etc... . There's seems to be a billion problems all of a sudden.
          >>
          >I have option strict turned OFF in my development environment. Is it
          >enforcing all of these errors that would normally have been generated
          >with option strict ON when running as an executable? Is there a way to
          >get around it at all? I don;t understand why it runs perfectly fine in
          >dev but bombs out in a big way when running as an executable...
          >>
          >Thanks,
          >>
          >Brad
          >>
          >

          Comment

          Working...