I wrote a program in VB.NET and created DLL files and used the COM objects in the registry. Now I want to run my program on another computer where I don't have Visual Studio. I am confused which files from my original project should I copy, where to copy and what to do afterwards? The question might seem too general but its the first time I have to run my program on other computers, so any help would be highly appricieated.
Related
my problem is :
I have a VB .NET project, with an installation project made with the old poor "Visual Studio Installer".
The version of Visual Studio I'm currently using is 2015.
Now I need to insert into the installer project a huge amount of file, from different directories,
and the IDE doesn't let me to add multiple files in subdirectories, with a simple "copy and paste into".
Apparently, I have to manually create, into the file system, every sigle directory that I want to have in the final installation.
I've already did a little program that inserts those files programmatically into the main project file (.vbproj), that's simply an xml file, but the .vdproj file seems more "tricky" do manage,
it contains GUID numbers, as 9F6F8455-1EF1-4B85-886A-4223BCC8E7F7 that I'm not sure I'd want to tangle with.
Anyone has ever dealt with a problem like this?
I solved by myself.
Simply I was wrong, you can actually copy the directories you want to add, from a file explorer windows, and then paste it into the File System Windows of the installation project.
Anyway, I think I'm leaving here this question, in case anyone else would need that.
I have a Visual Studio solution which I'm trying to build using the Incredibuild tool. Two of the projects in the solution work in tandem - the first project (we'll call it "Project A") builds an executable (foo.exe) which can parse a data file in the second ("Project B") to generate some header files.
Obviously there is a dependency on Project A defined in Project B. If I use Incredibuild's Rebuild Project option on Project B, it correctly builds Project A and foo.exe is successfully built. Project B has a custom build tool file which should cause foo.exe to be ran with a command-line argument to the file it's supposed to parse. However, trying to launch foo.exe in this way always returns an error:
CustomBuild:
Running Foo
'path to executable\foo.exe' is not recognized as an internal or
external command, operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
Interestingly, if I then use Incredibuild to build only Project B (i.e. using the Build Project option), everything is ok - it correctly picks foo.exe from the location it was built to on the previous, failed, build. This makes me think that the path, at least, must be ok.
Can anyone suggest why the executable cannot be ran as part of the rebuild? Is it a timing issue, e.g. Project B commences before foo.exe is known to the file system??
It all works under Visual Studio's regular (re)build. It's just the Incredibuild rebuild which fails. Note that I'm doing all of this through the Visual Studio IDE, not from a command line.
Edit: this is the freebie version of Incredibuild that I'm using (the one which comes with Visual Studio), so all of the build is on the local machine.
I contacted the Xoreax technical support about this in the end and they told me that this is a "rare but known issue that is related to one of our extra accelerating features".
Their first suggestion was writing an executable which simply sleeps "for a few milliseconds" and having that run as part of the custom build tool post-link. This did indeed solve the immediate problem, but the solution I'm building has numerous similar problems and adding this delay in everywhere quickly became tedious and didn't always work. It felt like a fudge anyhow.
So I asked if this behaviour can be toggled to off, and indeed it can. In Visual Studio the Incredibuild menu has an Agent Settings option, and from the invoked dialog's Visual Studio Builds|Advanced page it's a simple case of unchecking the Enhance throughput using out-of-order tasks spawning option.
Case closed.
There are options how to offload or intercept custom tools during your build process. Try to look onto "c:\program files (x86)\IncrediBuild\Samples"
I just finished coding my c program in visual studio (VS) and what I had done is just drag the compiled .exe file out of the folder to run it on other computers, except on other computers for that to work I guess I need VS since it says the MSVCR110D.dll is missing which is from VS. So how can I run my program on other computers that don't have VS?
You can use IExpress which is used for distributing self-contained installation packages. It is there in every windows machine preinstalled. Using this utility you can make the executable .exe which will be incorporated with dependent dlls. You can see Step by step guide, to see how to use it.
Follow these steps
https://msdn.microsoft.com/en-us/library/3w7axy17.aspx
In your output window it will show you where you can find the exe file, usually something like "ProjectName/Debug/Release/"
If you have added any external libraries you will have to copy any DLL files in that folder with the exe (You can combine them with some applications if needed)
You will also have to make sure that you have the correct version of the .NET Framework on the PC that you are trying to run your program on
I have a project in visual C 2010 that needs real-time timing in high priority to eliminate stuff like hard disk maintenance and stuff.
I ran the .exe file of my project using start "" /high & start "" /realtime.
(described here: https://superuser.com/questions/31802/starting-visual-studio-as-a-high-priority-process)
However, in the program I log the elapsed time and several other things, and running it this way stops the program updating the log files?
Note, for visual C, I found the .exe file in the debug folder with it's own separate set of log files.
you can use fflush() right after the logging statement so the data will be written to the disk.
see Flushing buffers in C
problem was, visual studio debug folder was write only. I was manipulating the .exe file in the debug, and that was why... take everything out into a new folder, and it should work!
I've been using Visual Studio 2005 for a few years and I've come across a problem which I'm wondering whether its me being stupid. I'm using Windows Vista and I can't debug a project with an assembly name containg the word "update" without running Visual Studio in administrator mode.
For example, I created a new windows forms application project leaving the default windowapplication1 assembly name and pressed F5 to debug and sure enough the project ran. I then amended the assembly name to UpdateManager and pressed F5 again. This time it wouldn't run and says its requires elevated permissions. Changing the assembly name to UpdatManager (no 'e') and it runs again?
Is this my setup or behaviour in built into Visual Studio?
Awesome problem. You are using an old version of VS, one that doesn't automatically embed a manifest in the EXE to signal Vista that your program is aware of Vista UAC policies. That makes it treat your program like a legacy program, it automatically redirects file and registry access to safe locations.
That works pretty well for old programs, except the ones that are intended to update, patch or install programs. There is no easy way for Vista to see that a program is an installer. Other than, you guessed it, the name of the program.
Start by installing the Vista specific service pack for VS2005. You probably also need to fix what your program is doing and make it UAC compatible.