Self contained app development...
-
I use vb.net for in-house development of apps. Many of these apps are small in size, with few if any referenced dlls. I'd like my apps to be *totally* self-contained--that is, I want to be able to drag and drop the contents of the app's directory onto a new machine and have it run *with no installation procedures*. In the past (vb.net 2003) this seemed relatively reliable, assuming that the dotnet framework was in place and that any referenced dlls or third-party components had their CopyLocal property set to TRUE. Since switching to vb.net 2006, this does not always seem to be the case. Apps that I have ported from 2003 to 2006, fail to run with errors like "The app encountered a problem....blah blah send a report to microsoft". This does *not* mean that I require an app to be a single exe file--only that *everything* required for the app is contained within a single folder that can be moved from machine to machine. Is there a 100% accurate manner of making an app totally self-contained in that it will run on a machine with the (proper) dotnet framework installed? If not, is there a manner in which a more accurate error report can be generated on a (non-developer) machine with a bit more useful information--such as exactly what is missing?
-
I use vb.net for in-house development of apps. Many of these apps are small in size, with few if any referenced dlls. I'd like my apps to be *totally* self-contained--that is, I want to be able to drag and drop the contents of the app's directory onto a new machine and have it run *with no installation procedures*. In the past (vb.net 2003) this seemed relatively reliable, assuming that the dotnet framework was in place and that any referenced dlls or third-party components had their CopyLocal property set to TRUE. Since switching to vb.net 2006, this does not always seem to be the case. Apps that I have ported from 2003 to 2006, fail to run with errors like "The app encountered a problem....blah blah send a report to microsoft". This does *not* mean that I require an app to be a single exe file--only that *everything* required for the app is contained within a single folder that can be moved from machine to machine. Is there a 100% accurate manner of making an app totally self-contained in that it will run on a machine with the (proper) dotnet framework installed? If not, is there a manner in which a more accurate error report can be generated on a (non-developer) machine with a bit more useful information--such as exactly what is missing?
First, an app compiled on .NET Framework 2.0 CAN work on an older version of the Framework. BUT!!! Only if the app doesn't use functionality specific to the 2.0 version. So, if your client machines have the 1.1 version of the .NET Framework, they can still run the 2.0 compiled code, ... to a point. This is probably where your problem is comming in. Dave Kreskowiak Microsoft MVP - Visual Basic
-
First, an app compiled on .NET Framework 2.0 CAN work on an older version of the Framework. BUT!!! Only if the app doesn't use functionality specific to the 2.0 version. So, if your client machines have the 1.1 version of the .NET Framework, they can still run the 2.0 compiled code, ... to a point. This is probably where your problem is comming in. Dave Kreskowiak Microsoft MVP - Visual Basic
Dave, I'm not sure what you're saying here....is what you are describing that my new vb.net 2005 application (which uses framework 2.0) is trying to run using framework 1.0 and failing? Even though both frameworks 1.0 and 2.0 are *both* installed on the machine? Is it possible that I've compiled (in vb.net 2006) an app that is forcing itself to use the 1.0 framework by mistake? How would this be "deterred" if so?
-
Dave, I'm not sure what you're saying here....is what you are describing that my new vb.net 2005 application (which uses framework 2.0) is trying to run using framework 1.0 and failing? Even though both frameworks 1.0 and 2.0 are *both* installed on the machine? Is it possible that I've compiled (in vb.net 2006) an app that is forcing itself to use the 1.0 framework by mistake? How would this be "deterred" if so?
Any app compiled under .NET 2.0 (VB.NET 2005) will run under 2.0 first, if it's available. If not, it'll use the highest version .NET Framework installed, if possible. Using VB.NET 2005, there's no way you could possibly have compiled it under a 1.x .NET Framework by mistake. The compilers used by Visual Studio are not in Visual Studio, but are an integral part of the .NET Framework. If your app crashed, does anything show up in the machines event logs (Application, Security, or System)?? Dave Kreskowiak Microsoft MVP - Visual Basic
-
Any app compiled under .NET 2.0 (VB.NET 2005) will run under 2.0 first, if it's available. If not, it'll use the highest version .NET Framework installed, if possible. Using VB.NET 2005, there's no way you could possibly have compiled it under a 1.x .NET Framework by mistake. The compilers used by Visual Studio are not in Visual Studio, but are an integral part of the .NET Framework. If your app crashed, does anything show up in the machines event logs (Application, Security, or System)?? Dave Kreskowiak Microsoft MVP - Visual Basic
Ah. That makes sense...Since both frameworks are installed, it should be safe to assume that the correct version is being used. No, nothing in the event logs (any of them). Just the before-mentioned error message/dialog. Ideally, I'd like to be able to "self enclose" my in-house apps in a folder, then to installations by copying this folder to machines on our network. I've done this in the past with 2003, and even place folders of apps on a linux server that users on windows boxes can run from their desktops. However, since switching to 2005 this seems a bit more unpredictable. There has to be a reliable method of guaranteeing that all references for an app are in a folder to be copied to to local machine *without* having to perform a full install. Someone on a newsgroup suggested ClickOnce, but this seems just as skittish, and only installs for the current user.
-
Ah. That makes sense...Since both frameworks are installed, it should be safe to assume that the correct version is being used. No, nothing in the event logs (any of them). Just the before-mentioned error message/dialog. Ideally, I'd like to be able to "self enclose" my in-house apps in a folder, then to installations by copying this folder to machines on our network. I've done this in the past with 2003, and even place folders of apps on a linux server that users on windows boxes can run from their desktops. However, since switching to 2005 this seems a bit more unpredictable. There has to be a reliable method of guaranteeing that all references for an app are in a folder to be copied to to local machine *without* having to perform a full install. Someone on a newsgroup suggested ClickOnce, but this seems just as skittish, and only installs for the current user.
smarr wrote:
There has to be a reliable method of guaranteeing that all references for an app are in a folder
No, there isn't. Not all dependencies can be reliably traced by code and some dependencies are just assumed to be available on target machines. There are just too many different ways you can call code, both managed and unmanaged, that reside outside of the assemblies of your app. You have to test your distributions before you roll them out to the masses. I like to distribute Debug code to a couple of test machines (VMWare or Virtual PC comes in real handy for this!) to make sure it works before I retest it again using Release versions. This does a pretty good job of catching those natsty little errors your seeing on your client machines. Dave Kreskowiak Microsoft MVP - Visual Basic
-
smarr wrote:
There has to be a reliable method of guaranteeing that all references for an app are in a folder
No, there isn't. Not all dependencies can be reliably traced by code and some dependencies are just assumed to be available on target machines. There are just too many different ways you can call code, both managed and unmanaged, that reside outside of the assemblies of your app. You have to test your distributions before you roll them out to the masses. I like to distribute Debug code to a couple of test machines (VMWare or Virtual PC comes in real handy for this!) to make sure it works before I retest it again using Release versions. This does a pretty good job of catching those natsty little errors your seeing on your client machines. Dave Kreskowiak Microsoft MVP - Visual Basic
Correct me if I'm wrong here, but wasn't one of the tenets of DotNet that--because dlls and "called components" could all be contained within an app's installation folder--that it cured DLL hell-type issues like this? If the installer gets the information on what to install from the app itself, and the installer works but copying all the listed references does not, then by association the installer is doing something *extra* that it is not being told by the app (or at least, the info isn't visible to the user). There has to be a manner of seeing this info so that I can manually copy those file independently and make sure they are there. Perhaps an app that can detect what refs are being called during an app's execution.....