Just curious, why is the source code included in the 5.6.1 Install and Upgrade distributions?

Shouldn't they just include the aspx, ascx and dll files?  Why are all the .vb files included?  I don't want those out there on my production web server.

Is this just a mistake by the person who packaged up those files, or am I missing something?

Just a heads up - there are no security or safety risks associated with having code behind elements on a production server.
There is no way to access these files unless you have root access to the file system via tools such as an ftp server or a system level file management tool. IIS blocks all attempts to access such files at the server level.

Westa

1. if your site is so badly configured that you have managed to allow a user access to a .vb or .ascx file directly via a http call thru IIS, as opposed to thru the IIS pagehandlerfactory then you site would be non-functioning.  Access to all files in the asp.net ecosystem is controlled via IIS and its handlers and filters - these would effectively need to be deactivated to access such a file.

2. if your site is exposed via FTP then you have much bigger issues than some user having access to generic DNN .vb UI code that can be downloaded for free by anyone with a web browser.

3. in fact anyone can download a decompiler for asp.net dll's - there are both free and commercial ones that can pull apart any dll and revert it to c# or vb in a matter of seconds.

4. There is actually very little performance difference in asp.net 3.5 between code in a dll and code in a .vb file.  There is a tiny impact on the first access to a .vb code page during which time the page is compiled and stored in the compile cache - but apart from that one off hit - they both run at exactly the same speed.

5. There are however HUGE development time gains to be had from developing using the WSP model for UI interface layers if your code is effectively open source.  The main advantage is no compile cycle during development ... code can be modified and run with a simple page refresh of your web browser ... as opposed to a compile cycle inside visual studio and a complete restart of the application pool inside asp.net due to a file in the bin folder being updated.

6. As for exposing your sensitive encryption format - well thats where the beauty of asp.net comes to the fore.  You CAN put code in a dll if you like - and in DNN all the core business rules, data providers, http providers - and many 3rd party modules work this way.  But for you generic UI layer it makes a lot of sense to NOT do things that way.

In dnn there are hundreds of UI modules and components that make up the visual interface that is seen by users.  These are often developed by different people and in different locations - by moving all these elements to a WSP model - there is no NEED for separate projects and dll's for each of these modules - something that would be a management nightmare.

Instead each of these modules and components simply exist with their aspx and aspx.vb code in a folder inside the WSP project - and get compiled on the fly when needed. 

Just my 2 cents.

Westa