All of a sudden my VS.NET program will no longer stop at a breakpoint, not in any file.

Since I last successfully did stop at a breakpoint
1) I have uploaded a copy of the program to a Web Host. During that time I changed the Database Connection string, but I've changed it back,
2) I deleted a sub-directory that was used, but was not included in Solutions. I also deleted the code that referenced it. And I've tried it after replacing that sub-directory.
3) Have rebooted several times, and shut completely down.
4) In Web.config
    <compilation
         defaultLanguage="c#"
         debug="true"
    />

What could be causing the inability to stop at a breakpoint?


Sandy

__________________
Sandy

Hi Sandy,

I am sure you checked this a thousand times before, but you're not trying to Debug a Release build, are you?

Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

The configuration manager shown after selecting Solution ->Configuration Manager is set on debug. But I can't find a way to get to the larger Configuration Manager. (Like the one in C#.) I haven't changed anything in Web.config, but just in case this is it:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>

    <appSettings>

        <add key="ConnectionString" value = "data source=ANASAZI;initial catalog=nle;integrated security=SSPI;persist security info=False;workstation id=ANASAZI;packet size=4096" />

    </appSettings>

<system.web>

    <!-- DYNAMIC DEBUG COMPILATION
         Set compilation debug="true" to enable ASPX debugging. Otherwise, setting this value to
         false will improve runtime performance of this application.
         Set compilation debug="true" to insert debugging symbols (.pdb information)
         into the compiled page. Because this creates a larger file that executes
         more slowly, you should set this value to true only when debugging and to
         false at all other times. For more information, refer to the documentation about
         debugging ASP .NET files.
    -->
    <compilation
         defaultLanguage="c#"
         debug="true"
    />

    <!-- CUSTOM ERROR MESSAGES
         Set customError mode values to control the display of user-friendly
         error messages to users instead of error details (including a stack trace):

         "On" Always display custom (friendly) messages
         "Off" Always display detailed ASP.NET error information.
         "RemoteOnly" Display custom (friendly) messages only to users not running
         on the local Web server. This setting is recommended for security purposes, so
         that you do not display application detail information to remote clients.
    -->


        <customErrors mode="RemoteOnly" defaultRedirect="ErrorPage.aspx" />

    <!-- AUTHENTICATION
         This section sets the authentication policies of the application. Possible modes are "Windows", "Forms",
         "Passport" and "None"
    -->

    <!-- APPLICATION-LEVEL TRACE LOGGING
         Application-level tracing enables trace log output for every page within an application.
         Set trace enabled="true" to enable application trace logging. If pageOutput="true", the
         trace information will be displayed at the bottom of each page. Otherwise, you can view the
         application trace log by browsing the "trace.axd" page from your web application
         root.
    -->

        <authentication mode="Forms">
            <forms name="NoLimitEnginAuth" loginUrl="Login.aspx" protection="All" path="/" />
        </authentication>

    <trace
        enabled="false"
        requestLimit="10"
        pageOutput="false"
        traceMode="SortByTime"
        localOnly="true"
    />

    <!-- SESSION STATE SETTINGS
         By default ASP .NET uses cookies to identify which requests belong to a particular session.
         If cookies are not available, a session can be tracked by adding a session identifier to the URL.
         To disable cookies, set sessionState cookieless="true".
    -->
    <sessionState
            mode="InProc"
            stateConnectionString=""
            sqlConnectionString="data source=;user id=sa;password="
            cookieless="false"
            timeout="20"
    />



    <!-- GLOBALIZATION
         This section sets the globalization settings of the application.
    -->
    <globalization
            requestEncoding="utf-8"
            responseEncoding="utf-8"
/>

</system.web>

<location path="Checkout.aspx">
        <system.web>
            <authorization>
                <deny users="?" />
            </authorization>
        </system.web>
</location>
<location path="OrderList.aspx">
        <system.web>
            <authorization>
                <deny users="?" />
            </authorization>
        </system.web>
</location>
<location path="OrderDetails.aspx">
        <system.web>
            <authorization>
                <deny users="?" />
            </authorization>
        </system.web>
</location>
</configuration>

I've removed and recreated the only file I thought that might cause a problem, but that had no effect.

I'm out of ideas.


Sandy

Hi Sandy,

I don't have an answer (yet), but you may want to edit your previous post. Posting public IP numbers in combination with a user name and password doesn't seem like a smart thing to do...... So, if I were you, I'd edit the post before Google finds it....


Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

I think the "Larger Configuration Manager" you are referring to is actually the Properties dialog for the project. Choose Project | Properties, and then open the Configuration Properties node. Under Debugging, make sure that at least ASP.NET debugging is selected.

You may also want to check the other panes of the dialog and check if everything has been configured correctly.

Also, check the Properties dialog for the Solution (right-click the Solution and choose Properties). Is your project set to be build?

Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Thank you Imar,
I have,

Project Property Pages:

Common Properties:
General:
Startup Object: (Not Set) - Although I have set this and it has always started on that page.

Configuration Properties:
Build:
General Debugging Information: True
Debugging:
Enable ASP Debugging: False
Enable Asp.Net Debugging: False
Enable Unmanaged Debugging: False
Enable SQL Debugging: False
Start Action:
Debug Mode: Project
Start URL:
Start Page: NLELogo.asp
Start Options:
Command Line Arguments:
Working Directory:
Alwaus use Internet Explorer: True
Enable remote debugging: False
Remote debug machine:


After changeing Enable ASP.NET debugging: True, I can now debug. Could you explain why the Startup Object is not set. And shouldn't I enable SQL debugging as I'm using SQL Server. Is there anything else that could be improved.



Sandy

I'd say that Enable Asp.Net Debugging should be set to true as well.

SQL Server debugging is not really required just to work with SQL Server. However, if you want to step into and debug Stored procedures (a really cool feature), you'll need to enable it.

AFAIK, the Startup Object is not used in ASP.NET projects. You see it used in Desktop and Console application that have a Main method where the program execution begins.

In your ASP.NET project, Start Page is what determines the debug start (in combination with the Startup Project, if you have multiple projects in your solution). In your case, this is set to the "classic ASP page": NLELogo.asp

HtH,

Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.