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.
Related
I have created a GUI and Database for my company. I am trying to alpha test the program. I made the program so that everyone would place it on their C drive so that the file paths would stay consistent. When I email the zip folder to everyone it adds an extra folder that is causing errors to the file path (I believe the error occurs during extraction?). Does anyone know a good way to prevent this from happening? Thanks!
Although "xcopy deployment" is a valid method to deploy programs, it can come with complications, as you have discovered. Instead, you can create an actual installer program which is much more versatile.
For a lead-in on making an installer you can read Create MSI installer in Visual Studio 2017.
Make sure that the program uses locations as given in the Environment.SpecialFolder Enumeration so that it is automatically adapted for any (properly-configured) Windows installation.
Other installers are available, e.g. Inno Setup, which may offer simpler or more detailed configuration of some options like replacing or keeping older files, or installing prerequisites like a required framework version.
We are facing situation when some developers modify the project file (*.sqlproj) for example by adding or removing objects, then they do not save all the files in the Visual Studio and try to commit/push changes using command line. In that case the *.sqlproj file is not saved yet and it is not caught by the git. There is no problems when you commit/push from Visual Studio as it warns you that you have not saved files and asks you what to do.
So the question... Is there a way to find that the file is modified, but not saved yet? Maybe there are some temp files location or any other proper way of doing that?
I've packaged my WinForms app with the Visual Studio Installshield Limited Edition wizard.
When installing the app, I get this error during installation.
Error 2715. The specified File key ('myappname.xml_serializa') not found in the File table
Any ideas from anyone? I'm completely loss on this one.
In your installer project directory, open the *.isl file and search for the text in your error message, myappname.xml_serializa. It will most likely be in there quite a few times. Either remove it or correct all instances of it.
I had a similar problem recently and found out that it didn't find the key because I was not adding the .primaryoutput file on the section Specify Application Data -> Files. Check if you are adding all the necessary files for your setup before creating the installer. The installer will be created even if it doesn't have all the files, but it won't execute properly.
Hope this helps
Changing the *.isl file resolved our issue. I found that we had changed the .NET framework of a project and when we removed the project output from the Installshield using the prompt it did not update this file so when we added the output again it now contained two outputs. OUTPUT and OUTPUT1. Hope this helps
This is what worked for me: The project in my case was readonly as it was connected to TFS. If you are working offline, make sure you make the project files writable. (Uncheck Read Only at the folder level)
This worked for me:
In your setup project double-click Project Assistant.
Click on Application Files.
Select file(s) with the file extension that was reported in the error message(s).
Click on Delete.
Repeat for any files as needed.
Go back to setup project in Solution Explorer.
Click on Rebuild
I have wrote an application that consists of two projects in a solution, each project contains only 1 .c source file. I was using Visual Studio 2010 Ultimate but due to the University only supporting 2008 I decided to create a blank solution and copy the source files into the new one.
After creating a new solution in VS2008 express, creating two projects and re-creating and adding the source files to the projects I ran the application.
For some reason only one part of the application does not work, I use CreateProcess() to execute "Project1.exe" from Project 2.
This works fine under vs2010 but for some reason it's not working under VS2008 express, GetLastError() is showing an Error 2: File Not Found.
This is an image showing the same code in both IDE's:
I'm not using anything special and I've made sure that both solutions/projects are using .Net 3.5.
I can't work out why it would work for one IDE and not the other.
Any suggestions? Thanks!
Edit:
Screenshot of .exe's
You are not passing the full path name of the .exe to CreateProcess(). This usually only works if you are lucky. The .exe files would have to be in the same directory and the working directory has to be set to that directory. First verify that the .exes are where you hope they are.
Avoid the dependency on the working directory by generating the full path to the 2nd .exe. Use GetModuleFileName(), passing NULL, to get the full path of your 1st .exe
Suppose you have some source code that comes from the unix world. This source consists of a few files which will create a library and a lot of small .c files (say 20 or so) that are compiled into command-line tools, each with their own main() function, that will use the library.
On unixy systems you can use a makefile to do this easily but the most naive transformation to the windows / Visual Studio world involves making a separate project for each tool which, although it works, is a lot of work to set up and synchronize and more difficult to navigate at both the filesystem and project/solution level. I've thought about using different configurations where all but one .c file are excluded from the build but that would make building all the tools at once impossible.
Is there a nice way of building all the tools from a single "thing" (project, msbuild file, etc.)?
I'm really not interested in using cygwin's gcc/mingw or NAnt. I'd like to stick with the standard Windows toolchain as much as possible.
You don't HAVE to use visual studio to compile code. You can make your own batch file or Powershell script that simply calls the compiler on your source, just like a makefile.
So I've been looking into this for a while now and the solutions all leave much to be desired.
You can...
Create a lot of small projects by hand.
Use MSBuild and deal with its steep learning curve.
Use a build tool that does not integrate well with Visual Studio, like GNU make.
You can't even make a project template like you can with .NET projects! Well, you can make a wizard if you want to wade through the docs on doing that I suppose. Personally, I have decided to go with the "many small projects" solution and just deal with it. It turns out it can be less horrible than I had thought, though it still sucks. Here's what I did in Visual Studio 2008:
Create your first Win32 command line tool project, get all your settings down for all platforms and make sure it works under all circumstances. This is going to be your "template" so you don't want to edit it after you've made 20 copies.
(optional) I set up my paths in the visual studio project files so that everything is built in the project directory, then I have a post-build step copy just the dll/exe/pdb files I need to $(SolutionDir)$(OutDir). That way you can jump into a single directory to test all your tools and/or wrap them up for a binary distribution. VS2008 seems to be insane and drops output folders all over the place, with the default locations of Win32 and x64 output differing. Spending a few minutes to ensure that all platforms are consistent will pay off later.
Clean up your template. Get rid of any user settings files and compiler output.
Copy and paste your project as many times as you need. One project per tool.
Rename each copied project folder and project file to a new tool name. Open up the project file in a text editor like Notepad++. If you have a simple, 1-file project you'll need to change the project name at two places at the beginning of the file and the source code file name(s) at the end of the file. You shouldn't need to touch the configuration stuff in the middle.
You will also need to change the GUID for the project. Pop open guidgen.exe (in the SDK bin directory) and use the last radio button setting. Copy and paste a new GUID into each project file at the top. If you have dependencies, there will be one or more GUIDs at the bottom of the file near the source code. Do NOT change them as they are the GUIDs from the dependencies and have to match!
Go into Visual Studio, open up your main solution and add your tool projects.
Go into the configuration manager and make sure that everything is correct for all supported platforms, then test your build.
It's not beautiful, but it works and it's very much worth the setup time to be able to control your builds from the GUI. Hopefully VS2010 will be better about this, but I'm not too hopeful. It looks like MS is giving a lot more love to the .NET community than the C/C++ community these days.
If you have a makefile you can use a 'makefile' project in Visual Studio (which in misnamed - it simply allows you to specify custom build/debug commands), and use it to invoke GNU make.
You will need to change the makefile to use the VC++ command line tools instead of cc or gcc or whatever it uses, but often these are specified by macros at the top of the makefile.
If the makefile uses other Unix specific commands (such as rm), you may need to make modifications, or create bath files to map commands to Windows equivalents. Another option is to install any necessary tools from GNUWin32 to make it work.
If the build is very complex or involves configure scripts, then you have a harder task. You could generate the makefile from a configure script using MSYS/MinGW, and then modify it as above to make it work with VC++.
Makefile projects will not be as tightly integrated in Visual Studio however. All the build management is down to you and the makefile.
If you're really using Visual Studio, I would suggest creating a project for each tool, and adding these projects to a single solution. From Visual Studio, it's easy to build a complete solution all at once, and MSBuild knows how to build .sln files as well.
msbuild myslnfile.sln
or even:
msbuild
... will build your solution.