If you wish to run your module as a PA (and I suggest that you do, for ease of development, packaging and upgrading) then you will not be running 'code behind' in your ascx files. Building as a PA means you can just have the single module loaded into yoru developement envirnoment : a simple .bat file to copy the compiled dlls and .ascx into the /bin directory and desktopmodules/project directory (respectively) of your target test environment will then do the job of applying the changes. THis is much faster than keeping the entire DNN Codebase loaded into your code editor and having to recompile the whole thing each time. You can also put in a command line parameter and send the files to different test installs, for quick testing of different configurations and DNN versions (if necessary)
For my custom modules, I always build a DLL as a PA. You would normally structure the project like this (I know you're developing in .vb, but the principles are the same):
project name
.. DataProvider.cs
..ProjectController.cs
..Entities
.....Entity1Info.cs
..UI
.....UserControl1.ascx
....UserControl1.ascx.cs
....App_LocalResources
......UserControl1.ascx.resx
....Project.dnn
....module.css
That's the basic structure of the DLL. Note that because it is a class library, you can't 'add' a .ascx file using the menu - either copy one in from somewhere else or add a text file and rename it.
The top of your user control should have this declaration (again, in C#, but you can change to VB easily)
<%
@ Control language="C#" AutoEventWireup="false" Inherits="Project.UI.UserControl1" %>
Notice there is no mention of codebehind, codefiles or anything else. Just the type (class) that the .ascx file 'belongs' to. Of course, this is the type of the .ascx.cs file that is 'built' into your DLL.
This means you can't use the double-click functionality of visual studio to create your events, and you'll have to manuallly code in the declarations for the controls on the user control file. But as a talented ASP.NET programmer, that's not a problem for you, is it? :-)
When you package, don't distribute any code files (.vb/.cs) in your package. There should be none in the .zip file, none mentioned in the .dnn file. Just package the .ascx, .resx and .dll file and it will all work out the way you want.
Incidentally, this was the advice in early 4.0 days for building all modules. It's only later on in the DNN life cycle that the app_Code folders started to get used. It's still OK to use them for quick'n'dirty apps, but if you want to build a lot of modules, you'll soon tire of having to recompile the entire DNN website in order to make changes and test them. The app_code style to me is for people who are just getting started with DNN and want to do lightweight, quick modules. If you're building serious code then go for a PA approach.
Hope this helps
-Bruce