views:

125

answers:

2

I am using VS2010 VB.NET, working on a solution that has a number of projects. I have been developing on it for a while now, and in an attempt to debug a custom class inherited from ObservableCollection (which by the way would not load symbols when debugging even though it was apparent that the breakpointed line was being called), I changed the startup object for the startup project to a different WPF window which I had a couple of controls that I set aside for debugging.

Immediately I was confronted with 'Sub Main' was not found in . I tried changing the startup object back to the normal startup window, but now the Startup Object dropdown only has "Sub Main" as it's only option. I changed the StartupURI back in the App.xaml, to no avail.

Anyone else seen this?

How can I get it back to using the original window?

As a side note, is there a setting somewhere that would cause the debugger not to load symbols for an assembly? I know the DiskCollection class is being instantiated, but a breakpoint on the constructor always says Breakpoint cannot be hit, No Symbols loaded.

Cory

+1  A: 

The startup in WPF is different then in winforms; it's set by the App.xaml file. Edit that in xaml mode and you will notice this:

<Application x:Class="WpfApplication6.App"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         StartupUri="MainWindow.xaml">
<Application.Resources>

</Application.Resources>

The StartupUri sets which form will start things.

If you wanted code to kick things off instead you can remove the StartupUri and do this instead:

Startup="Application_Startup"

Then provide the code in the App.xaml.cs file like so:

public partial class App : Application

    {
        private void Application_Startup(object sender, StartupEventArgs e)
        {

        }
    }
Kelly
It turns out that Enable application framework was not checked which I suppose tells it to use a window instead of the App.xaml.vb/cs file for initial execution. Even though the window was properly given in the App.xaml file, this application framework setting appears to be separate from the app.xaml and affects whether the compiler uses the StartupURI attribute found there.
OffApps Cory
A: 

So aparently in the Project Properties page, the Enable application framework setting was unchecked. this apparently tells the compiler to use the StartupUri attribute to determine the startup page instead of using the main sub (or method; does this setting appear in C#?).

Somehow the setting was unchecked and so Sub Main was the only option in the StartupURI dropdown, the Windows Application Framework Propertie3s group was disabled, and the StartupUri attribute in the app.xaml was unused.

Now I know...

Cory

OffApps Cory