One way to deploy database for SQL Server

For using sqlcmd , see:
http://msdn.microsoft.com/en-us/library/ms180944.aspx


put this in a batch file:

set UName=smedlyuser
set DbName=funbeanweb
#set SName=localhost/SMEDLY
set SName=10.10.10.299,5422
set Pwd=supersecretpassword

echo drop_tables.sql... > _output_.txt
sqlcmd -S %SName% -U %UName% -P %Pwd% -d %DbName% -I -i drop_tables.sql >> _output_.txt 2>&1
echo create_tables.sql... >> _output_.txt
sqlcmd -S %SName% -U %UName% -P %Pwd% -d %DbName% -I -i create_tables.sql >> _output_.txt 2>&1
echo thing_data.sql... >> _output_.txt
sqlcmd -S %SName% -U %UName% -P %Pwd% -d %DbName% -I -i thing_data.sql >> _output_.txt 2>&1

@notepad _output_.txt

Deploying .NET Apps: extraneous files in bin: vshost

More info on how to turn off the creation of the unnecessary files:

http://stackoverflow.com/questions/3043843/vb-net-can-the-exe-built-by-vs2005-be-deployed-as-a-standalone-exe


On MSDN http://blogs.msdn.com/b/dtemp/archive/2004/09/09/215764.aspx :

If you have been using the new Visual Studio 2005 beta you have noticed a few new files showing up in the "bin" folder with the word "vshost" in the filename. For example, when you create a new WindowsApplication and hit F5, you may notice files named "WindowsApplication1.vshost.exe" and "WindowsApplication1.vshost.exe.config". This post is intended to shed some light on the reason why these new files exist, and answer a few common questions that people have been asking about them.

What is "vshost"?

This is the "hosting process". It is created whenever you build a project in the Visual Studio 2005 IDE. Its purpose is to provide support for improved F5 performance, partial trust debugging, and design time expression evaluation.

Improved F5 performance. As everyone knows, when you hit F5 your program is run. However, running a managed application requires the creation of something called an "AppDomain", which houses the runtime environment within which your application runs. It actually takes quite a bit of time to create an AppDomain and initialize the debugger along with it. This introduces a lag which is particularly noticeable when you are doing it over and over again. The problem is exacerbated by the fact that when your application ends, all of the AppDomain and debugger state is lost. When you hit F5 again, everything must be created and initialized again. The hosting process speeds up this process by doing all of this work in the background before you hit F5, and keeping the state around between runs of your application.

Partial trust debugging. A new feature in Visual Studio 2005 is the ability to debug applications in partial trust with permission settings as defined on the new Security page. When you deploy a partial trust application, it runs in a limited security context automatically. However, simulating a partial trust environment within Visual Studio under the debugger requires special initialization of the AppDomain, which is handled by the hosting process.

Design time expression evaluation. Another new feature in Visual Studio 2005 is the ability to test code in your application from the immediate window, without actually having to run your application. The hosting process is also used to execute your code under design time expression evaluation.

What's it doing in my "bin" folder?

There are numerous technical reasons why the "vshost" files must be in the same folder as your program. When your application is run within the hosting process "vshost" is the top level executing assembly in the AppDomain, not your application. Therefore assemblies, config files, and ClickOnce and side-by-side manifests cannot be properly loaded in all scenarios unless the "vshost" files are in the same folder with all of the other files.

Should I deploy the "vshost" files with my application?

No. The "*.vshost.exe" and "*.vshost.exe.config" files are only for use in the Visual Studio 2005 IDE. They should never be run directly, and they shouldn't be deployed with your application.

Can I disable generation of "vshost" files?

In Beta1 this feature is always enabled for all "Windows" application project types. In Beta2 we do plan to add an option to disable this functionality, but of course you would then loose the benefits outlined above. If you are experiencing a problem in the beta that you think may be related to this feature, please report a bug!

Deploying .NET Apps

Jacques Bourgeois of Devx.com says:

.NET files do not need to be registered, unless you want to call them from a COM (VB6) application.

The possibility of deploying a project only by copying the file is possible in .NET, but it depend on the dlls used by the project. This is called XCOPY deployment, because of the XCOPY command that was used in DOS to copy a batch of files.

Here are a few basics to guide you, but it is surely not complete. Every situation is different, because every application uses its own set of dlls.

The first thing is to make sure that the users have the proper version of the framework. An application developed on the framework 2.0 should work with the framework 3.0, but not the reverse.

If the application uses only dlls from the framework and the user has the proper version of the framework, no problem.

If the compiler copied dlls in the compilation directory, then those should also be copied and put in the same directory as the application on the user machine as was suggested by many.

The main problem with such a deployment, when it works, is that the user has to start the application from Windows Explorer or manually create the necessary shortcuts.

Everything is not always so simple however.

In the following situations, you will probably have to resort to a Setup program, or at least a simple .bat or .vbs file to correct some of the problems associated with a straight copy.

In some compilations, needed files from outside the framework are not copied in the application directory upon compilation. This is most often due to third party dlls that do not install correctly in your development computer (Crystal Report is a good example) and do not instruct the compiler to copy them when they are referenced.

If you encounter that problem, you might try to change the CopyLocal property of the reference to True. However, it is not always that simple, because some of the dlls your application need might not show in the references (Crystal Report again).

If you reference a COM / ActiveX / VB6 dll in your application, it won't be copied in the compilation directory. You mostly end up instead with a dll that has the word "interop" somewhere in its name. This interop is a only bridge between .NET and the COM dll. In such a case, the interop must be distributed with the application, and the COM dll must already be installed on the user machine for the application to be able to use it through the interop.

Some applications such as Microsoft Office for example, can be installed with special interops called Primary Interop Assemblies (PIA). If you have the PIAs installed on your development computer, the compiler does not say anything and assumes that they are also installed on your clients computers, which might not be the case.

These are the situations that are encountered the most often. Depending on the dlls you use in your applications, you might find other situations that prevents you from simply copying the files on the user computer.

If users will use the application from the network (click on the .exe file located on a server), remember that security rules are not the same when the application is installed locally and when it runs from somewhere else, so be sure to check and test the application in an environment that is similar to the one in which it will work.

ClickOnce is also an alternative. It is a lot simpler to prepare a ClickOnce installation than to do so with a standard Setup package. It also tremendously simplify updates to the application. You might however be aware that this could also come with it own security limitations.

Simple tutorial for ClickOnce:
http://www.kirupa.com/net/clickOnce3.htm