How to share vb.net .exe from one system another system(min 6 systems) - vb.net

I developed Vb.net project.
My project name is Lone.
My front-end is Vb.net Backend is Ms Access.
I completed my project.
Now I copy the Lone.exe and put shortcut into my system desktop.
Now I want to run that Lone.exe to all system.
I don’t no how to share that one.
Tell me how I want to run my project to all system.
Note: In my system only having Vb.net.
Remaining systems doesn’t installed vb.net.

You have to install the correct version of the .Net framework on all 6 systems, you don't need the whole VB.Net development environment, just the framework. This might already have been installed using Windows Update or similar, so this step might not be needed.
Just try googling download .net framework x.x where x.x is the version you need and you should find a link to download the correct version from Microsoft if needed.
After that just copy that executable to each system and run it.

Related

Application works without installation

I created a program in vb.net in vb language. After that I created an installer (.msi) for the same in Advanced Installer program. I installed it on the computer and everything seems professional.
I copied the folder that contains the program and all its dependees and sent to to a different computer. I was surprised that the application (.exe) file works without installation!!
How can I make my application works only with installation?
Appreciate the help.
Advanced Installer has a licensing module that works for VB.NET apps too, which you can easily integrate into your installer.
However, this is in the Enterprise edition, and I assume you are using the free edition, as this sounds like quite a simple application/installer.
In this case you can try looking for an alternative OSS solution for a licensing/trial library.
Basically with this library every user that needs to use the software will need a key to activate it, so even if they copy the folder with the application files from Programs Folder, they will still not be able to run your app.

Publish vs. Release

I created a simple application in VB.net in Visual Studio 2013.
It's not a website or a web app, it's just a simple Calculator, I think I created it as a Windows Forms Application.
When I build the application in release mode, it builds and runs properly.
It puts the executable it built in: Documents\Visual Studio 2013\Projects\DataCalculator\DataCalculator\bin\Release
I can just send that executable alone to someone and the program works fine. So what is the purpose of all the other files?
Furthermore, there is a Publish button in the Build menu of VS2013. What does publishing the program do that the the release doesn't?
Also, when I click the publish button it asks me how the user will install the application. What if I don't want them to install it, I just want it to run from a simple click of the executable. So what is the purpose of publishing?
If by "all the other files" you mean .application, .manifest, .pdb, etc., they all have uses in various contexts. If your calculator is stand-alone, then it will only require the .NET Framework version you used to create it installed and the .exe itself.
I have used the Publish feature a few times - at a previous company - it's useful for 'transparent updates' to users. For example, the tools I created were published to a shared drive on the server along with the associated "other files". The users then installed the tool from the shared drive by clicking on the setup/install version, which creates a shortcut on their start menu/desktop/wherever. The beauty of this particular method, is that you can configure the application to automatically update when it is run; so I continuously improved the tools and every time a user ran one, it copied the newer exe to their PC and ran that, without any further updates/reinstalls from their perspective.
It worked quite well for small engineering tools, but I'm sure with larger/more complex applications with databases and backward-compatibility to worry about, it could cause headaches in many situations.
Release will only create an .EXE Application file which is executable in supported platforms, but database must be separately copied . where as publish will create a setup file along with database and the sub folders inside the project folder. It helps you to install your application in any computer which meets the requirements.
Click to refer Advantages and procedure for publish http://msdn.microsoft.com/en-us/library/vstudio/ms233806(v=vs.100).aspx

How to make a Vb.net file/program To Standalone .Exe

I have a project done in VB.NET and I want to publish it for distribution. I know that when I build solution It creates an .Exe. But that requires local resorouces. If I build for release I know it works but it still needs the .Net platform installed. Is there anyway to make a true standalone .exe or something that would run on a persons computer if they do not have .NET installed. Also the ClickOnce application thing is not a wanted Solution.
Is there any converter program that can do this for me?
The .NET framework represents the basic prerequisite to run a .NET program; equivalently than having Windows installed is the prerequisite to run a Windows program. Bear in mind that any Windows version includes the .NET framework (and, actually, it tends to involve top-priority updates and thus are automatically perfomed by Windows Update in many cases). A big proportion of the programs running on Windows created during the last 10 years are built on the .NET framework; a relevant proportion of the sites (like this one, for instance) are built on ASP.NET and thus the given server has to include the .NET framework. If overall compatility is a concern for you, you might rely on a-bit-old .NET version: the latest one in VS 2010 (4.0) should be fine for most of modern computers; but you can even rely on the previous one (3.5) to be completely sure. Lastly, bear in mind that a .NET program can also be run under a OS other than Windows (Linux or MacOS, for example); although, from my past experiences, these are not too reliable situations. Nonetheless, in case of being interested in other OS, you should do some research/testing on this front to see if the available options offer what you are looking for.
SUMMARY: the exe file generated by the Visual Studio is actually what you call "standalone .exe". One of its defining features is the .NET version (which can be changed in the Project Settings); a program can only be run on computers with a .NET framework (or equivalent) equal or newer than the one on which it was built. The 4.0 version should be OK for most of new/properly-updated computers; the 3.5 .NET would work with virtually any computer (although, logically, it includes less features than the 4.0 one).
---------------------------- UPDATE AFTER COMMENTS --------------------
From some comments, I have undertood that my statement wasn't as clear as I thought and this is the reason for this update
.NET is pre-installed in Windows only since Vista. XP does not include the .NET runtime by default. The reason for not having mentioned this issue in my answer was that having a XP Windows without .NET is highly unlikely. Firstly because this is a top-priority, automatic update and thus one of the first times the computer is connected to internet "Windows Update" will take care of this. And secondly because this is the basic framework for any Microsoft programming over the last 10 years and thus a Windows computer not having it will not be able to run almost anything. With this last sentence, I don't mind that most of the programs are built on .NET, but that for a Windows-based environment most of nowadays basic requirements do include .NET.
It was also pointed out that there is some compatibility problems between different .NET versions (that various side-by-side versions were required). The basic Microsoft approach to the different .NET versions is backwards compatibility, what means that a given .NET version can run any program built with that version or older. This is theoretically right, but not always right in fact. My approach to this problem is relying on a bit old .NET version (3.5) and not using too new/untested features (e.g., WPF). If you want a for-sure overall compatible program you should work quite a lot on this front (compatibility between versions is one of most typical problem of any programming platform), instead expecting Microsoft to take care of everything. Thus, in principle, just one .NET version (the last one) has to be installed (which, on the other hand, is not the case for a big proportion of computers; for example: computer including the 3.5 version being updated, over the years, to 4.0 and 4.5 by maintaining the previous versions).
Lastly, I want to highlight that my intention with this answer is not defending any programming approach over any other one; I am just describing what is there from the point of view of your question "can I remove the .NET part?" -> no, you cannot; there is no (sensible) way to do that. If you want to rely on a different programming platform you should get informed about it (I am sure that Camilo Martin will be more than happy to help you on this front). If you prefer to rely on .NET, be sure that you can generate an overall compatible program (to be run on Windows).
Easy way to convert in .exe in VB.NET-2010:
Create New Project
Select Windows Application And Save Proper Path
Comple Project then Select File-> Save All
Select Build->Start Build
Your Project .exe Created Your Project Save Path:
Select Windows Application 1
Select bin Folder
Select Debug Folder
And in Debug folder your .exe File is ready.
Quick Basic once made and executable (.exe) directly form their VB code, but I wouldn't recommend converting to Quick Basic. You can look at Mono to see if they have anything yet. (mono allows you to use compiled vb.net in other operating systems).
Ezirit Reactor makes a single executable, but it's not free.
You can bundle .NET Framework into your distribution so that users don't have download it.
Why do you need an executable (.exe)? If the reason is for security and to minimize chances of reverse engineering, then get a good obfuscator.

Windows 8 Metro App Side Load Deployment

I am currently developing a Windows Store App that will eventually be targeted at the ARM devices when they are available. For now, I have been developing and testing from Visual Studio on my desktop computer and everything works fine. However, when I try to create an app package that I can pass along to others within my company for testing purposes, the application will not run properly.
The solution includes two projects. The first is a C++ project that is set to build a dll file. The purpose for this is to expose the Direct2D and DirectWrite libraries that seem to be unaccessible to a C# project. The second project is the C# project that references this dll for drawing functions and includes a XAML interface and most of the program logic. All of this works flawlessly on my development machine from within Visual Studio (and also when installing the package).
When I send the package files to other individuals within the company, the installation appears to work fine by installing with the PowerShell script. The tile appears in the start screen and the program will launch for a few seconds. The C# and XAML interface appears, but the DirectX portion of the application is not visible and the entire application shuts down within a few seconds. This makes me believe that the dll may not be installing or referenced correctly upon installation. I have checked the package file, and the dll file is included in the package after the build process is complete.
I have packaged a few different test programs (MSDN Samples) that have all installed on their machines, but we get the same results that they will not run (again, all samples run fine on my development machine when building them). The only test project that worked properly was a simple C# project that did not use DirectX at all. Any of the DirectX samples that I tried have all failed (including the native C++ samples that do not use C# at all).
To be clear, the process I use for building is going to Project -> Store -> Create App Packages and choosing the No option for uploading to the Windows Store.
Does anyone have any ideas on what might be going wrong with the build or installation process?
Thanks in advance for any help!
Does it work with the Metro Sideloader? I am not sure if it just adds a UI to the Powershell script, but it works for my team and me for testing...
Good luck!
Are you side loading a Debug version of your DirectX app onto a machine that does not have the Windows SDK installed? Visual Studio's default DirectX projects and the samples on MSDN both request the D3D11_CREATE_DEVICE_DEBUG flag when creating the D3D Device. Device creation will fail if the Windows SDK is not installed on the machine running the code.
Here are a few different options that will allow you to unblock yourself. Any one of these should give you the desired result:
Create a Release package and deploy that instead of a Debug package.
or - Go to DirectXBase.cpp and remove the D3D11_CREATE_DEVICE_DEBUG flag from the code.
or - Install the Remote Debugging tools for Visual Studio on the target machines. This will install the necessary SDK components to allow creation of D3D Debug devices. The other cool thing about this option is that once you're set up you won't have to create packages manually and side load them anymore. Just tell Visual Studio the name of your ARM machine and press F5 to deploy it remotely. More information here: http://msdn.microsoft.com/en-us/library/vstudio/bt727f1t.aspx
How are you deploying the native DLL with your project? Are you using project-to-project references? Can you verify that your DLL is ending up in the final package, in the root of the package application directory?
I recommend using Sysinternals Procmon to watch your application load on the target machine. If it crashes or fails, you can look in the log history for which DLL it is trying to load and failing. Typically this will show up as a repeated series of DLL load probes (it will try and load the dll from the application directory, and then proceed to try a number of other paths).

Microsoft Visual Studio 2005 (Vb.net)

I'm doing my project in Vb.net. my project name is "Bellows". My front end is Vb.net. Back end is Ms Access.
i Create My project in Windows Application
i complete my project. i copy the .exe file from "E:\BellowNet(new)\Bellows\obj\Debug" and put the shortcut into my desktop. now it's running.
similarly i copied my Bellows.exe from another system desktop but it not running.
How i want to run my Bellows.exe from another systems (maximum 10 systems).
Note : In my system only having Microsoft Visual Studio 2005. Remaining system doesn't have.
I put bellows.exe from another system. in that system doesn't having E Drive. it showing this error
The application Filed to initialize properly(0xc0000135). Click Ok to terminate the application
Similarly I put bellows.exe from another system. in that system having E Drive.
if i click that Bellows.exe the login form is open.. and main form is open. in that main form wen i click button it show the error.
Unhandled exception has occurred in your application. If u click continue the application will ignore this error and attempt to continue. If u click Quit, the application will close immediately. Could not load file or assembly ‘ADODB, Version=7.0.3300.0, Culture=neutral, PublickeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified
Good practice to run your project on another systems is to create its setup file and then install it on to another systems on which you want to run your project and of course you need to install .NetFramework as well with the same version which you used to developed your project. How to create setup and how to add Serial Key for those steps refer my blog
It sounds like either the .Net Framework is not installed on your target system or that there's an app.config file (Bellows.app.config) that you need to copy over as well.
Another thing that concerns me is what your expectations are for the access database. Do you want all the workstations to share a common database? If so, I highly recommend you convert your app to use Sql Server Express Edition (free). Access is an in-process database engine, and like all such engines it doesn't behave well when shared. If you don't expect them to share the database, you probably want to make sure you copy that *.mdb file over to your target machines as well.
Finally, let me re-iterate the advice in other answers about using a Release build and/or deployment project.
What errors do you see?
It could be:
The other system does not have .Net
framework 2.0 installed
You copied only the exe from the dev machine without other required files from the Debug directory (e.g., app.config, supporting DLLs).
If you are going to copy and paste the exe file then the all Prerequiest should be installed on that machine like framework.So make a setup file which is easy and add all Prerequiest on the setup after that do setup on new machine..
Thanks
I can only guess, but try this suggestions.
The application Filed to initialize
properly(0xc0000135). Click Ok to
terminate the application
.NET framework is not installed on this machine. Install the runtime.
Could not load file or
assembly ‘ADODB, Version=7.0.3300.0,
Culture=neutral,
PublickeyToken=b03f5f7f11d50a3a’ or
one of its dependencies. The system
cannot find the file specified
ADO.NET drivers are missing. You need to install Microsoft Data Access Components
You can avoid this problems if you make an install procedure and do the proper install on every machine.
The appropriate .NET framework must be installed in each machine as well as the appropriate MDAC. You can add them as part of the installation package.
http://msdn.microsoft.com/en-us/library/ms994427.aspx
And if you want to make it even more easier for your clients to get hold of it; use ClickOnce to distribute it from a central server.
http://www.15seconds.com/issue/041229.htm