I converted an MSI into an Installshield 2015 project by opening it in Installshield and choosing wizard.
The files in the project do not have path variable "link to" for them. Is there a way to create a path variable for them without removing and re-adding all of the files, so that I can build the project from command line and set the path variable using the -l parameter?
Use the Convert Source Paths Wizard: on the Project menu, click Convert Source Paths.
(Seen on Convert Source Paths Wizard, linked from the help topic David linked.)
Welcome to StackOverflow Damon.
This is completely do-able and is the standard way of configuring an InstallShield project. Check out this help file and let us know if you have any problems.
Related
I am using VC++4LD and I have set everything to work, it works perfectly, I like the extension, but I have 2 places in the project settings that can be improved.
1st place is Debugging->Program, I have something like "$(RemoteProjectDir)/subfolder/another_subfolder/gcc.cmake/OUTPUTNAME" there and it works, but I want it to be in a more correct way. By default, there was "$(RemoteBuildOutputs)" and that was incorrect. I can't even figure out, what is stored in that string => I tried to echo it in Pre-Launch Command with both "echo $(RemoteBuildOutputs)" and "$(RemoteBuildOutputs)", but nothing was shown. The project is built with a script that jumps into the "/subfolder/another_subfolder/" first.
So how to find, what is stored in $(RemoteBuildOutputs) and how to set the Debugging->Program dynamically so I can reuse it in other projects?
2nd place is Sources->Additional sources to copy, there is a lot of "CMakeLists.txt" files in the project and all are added to the project via "Include In Project", but they aren't copied to the remote machine during the build, I fixed it by specifying all the separate "CMakeLists.txt" files in "Copy Sources->Additional sources to copy", but it was a hard work to list them all.
How to automatically copy all CMakeLists.txt to the remote machine without specifying them separately so I can again reuse it in other projects containing any CMakeLists.txt?
EDIT: 1 more thing => I include linux project into VS with "Show All Files", then I select all folders and remaining files outside of them and choose "Include In Project" from the context menu, but all CMakeLists.txt remain unincluded in project, how to solve it, so I don't have to go through all of them and include them 1 by 1?
$(RemoteProjectDir) etc. are Visual Studio build macros that are expanded from pre-defined information like the project name and information entered into the project properties. They're not stored in environment variables. I don't know if there's a simple way to print the value of a macro but you can get VS to list the substitutions it makes by turning up the MSBuild verbosity : goto Tools/Options , Projects and Solutions / Build and Run page and set the MSBuild project build logfile verbosity to diagnostic (you probably want to use the log file 'cos it can spit out a lot of stuff).
As for CMake, various issues around it have been raised on the VClinux GitHub site . That would be the place to ask for enhancements. You might also look at VCLinux unoffical scripts to see whether any of Marc's scripts can help you automate the project creation.
You can open the Dropdown menu on that setting and click on <Edit>:
In the opening Window you'll see the expanded Macros:
In case anyone stumbles onto this because of the Edited supplemental question, I had the same problem in visual studio not adding every file after "Show all files" and hitting "Include in Project." Certain files like "makefile.am" and configure scripts were not getting included and therefore, were not getting copied over to the Linux system during build. My solution was to edit the .vcproj file and add a line that will include everything in a specified directory. This can be done for a specific folder or recursively.
For instance, if I wanted to add everything in folder "A" I would add,
<ItemGroup>
<None Include="A\*" />
</ItemGroup>
If I wanted to add everything in folder "A" and well as all sub-folders and sub-folder contents,
<ItemGroup>
<None Include="A\**" />
</ItemGroup>
Care should be taken not to double included items. Also, this should only apply to non-source items that will not be compiled. Otherwise the "None" indicator should be appropriately changed (CLInclude for headers, CLCompile for c/cpp, etc).
I have a library which includes samples of how to use the library along with unit tests.
I'm trying to create custom VS2012 solutions that will be in the deployment.
Depending on input given when initiating the deployment, I want to be able to create a solution - e.g. Samples.sln - which includes projects specified in the input file.
Example:
//inputfile1.txt
ProjectA
ProjectB
I run an MSBuild xml file or an F# script (or anything that can do this) and I get a Samples directory with a Samples.sln containing ProjectA, ProjectA.Tests, ProjectB, ProjectB.Tests
A similar thing would happen if I gave an input file with ProjectX & Project7... etc.
With MSBuild, I've figured out how to read the file input, copy project folders to a new folder, and do some other things I would need for this whole process but I can't figure out how to create and customize a solution. I'm not sure this is even possible with MSBuild - I think I can only alter an already existing solution (but I've had trouble doing this as well).
I figure I have these options:
A. Add all projects to a Samples solution, then use msbuild to turn them on or off
or
B. There exists some other way (not using msbuild) to do this whole process
Is msbuild even capable of A?
You should understand that MsBuild mainly is a build platform. It also happens to be able to read and write file etc but that's not it's core business. So while you can generate solution files for it, it's going to be pretty hard using just MsBuild as it's simply not meant to be able to do things like that directly.
Here's an option C: if you open an sln in the text editor you'll see the structure is quite straigtforward: for every project there's a Project ... EndProject. You could generate these strings in the proper format (that is, genareate guid, figure out relative path to solution, get project name from path, ...) in an MsBuild target, put all of them in an ItemGroup then write it to a solution files using WriteLinesToFile. Perfectly possible, but a lot of work and I wouldn't recommend it.
For your option A, that's even harder: to include/exclude projects from a build, VisualStudio uses the .suo files and those are in some binary proprietary format which I have no idea how to generate.
That leaves you with option B which is basically option C but without reinventing the wheel: find a tool that can generate solution files for selected projets and have MsBuild invoke it useing Exec. There are probably a bunch of tools that can do this, but here's an example using the first usable one I found on the internet called SolutionMaker. Suppose your projects are in directory Foo, you'd use it like this:
<Exec Command="SolutionMaker /s Foo/foo.sln /p Foo /v 2012"/>
since the corresponding command line options are
/s <solution>: Solution file path
/p <path>: project root path
/v <fileVersion>: New solution file will be generated in the specified format.
valid versions: 2008, 2010, 2012.
I am a first time user of this group and so pardon me for any mistakes and unclear statements.
What I am trying to do is to create single setup.exe (not msi) using installshield. But when I build the project what I get is other files along with the .exe file for e.g. .cab, .hdr, .inx and other such files.
I am using the options under Release -> Release Wizard -> General options-> Checked the "Create a single file executable" & "Compress compiled script" options but still I get the extra files along with the setup.exe file. I want a setup.exe file to be created independent of the other local files.
So could anyone suggest me how to achieve that.
Any help will be appriciated.
Thanks.
As Michael Urman wrote, you will find the one file in adjacent folder.
The folder name is "Package".
Those files are always created for InstallScript projects. When you build a single file executable, the single file version that packages it all together is available in an adjacent folder.
After automatically upgrading the project file for a .Net 4.0 web application to work with Visual Studio 2012 everything worked ok at first however when compiling I got lots of errors like this:
Description : Source File '..\..\..\..\..\File Path' could not be found
File : CSC
And when trying to build using MSBuild (passing just the project full path, with no additional parameters) in the "Developer Command Prompt for VS2012" I got basically the same errors:
"CSC : error CS2001: Source File 'x' could not be found"
All errors refer to Linked Files (aspx,cs,etc) located in other web applications projects located at a different deep in our code Branch (that's why all the '....\' at the beginning of the paths)
To me it looks like a problem with the file Length, I had the same problem a while ago when building the projects on our CI server using MSBuild, I was able to manage it by manipulating the project files before building them using a custom script without the need to move the branch around or reduce the deep of the projects, I didn't have to move anything, the important thing at the time it was that developers using Visual Studio 2010 could compile everything without problems. I learned by this that compiling/Building with MSBuild was different that with DevEnv/VS, and for example MSBuild didn't support building Setup projects and DevEnv did.
Since this is happening now with VS 2012/DevEnv 2012 , plus that VS 2012 doesn't support setup projects anymore (like msbuild), plus VS/DevEnv have the same problem with the file length, it looks like VS 2012 its finally using msbuild under the hood or are more tightly integrated, however I didn't find any article to confirm this.
Changing the branch structure/changing the deep of the projects it’s not an option right now due to several reasons (large code base, high number of projects, risk, timing, effort, etc.).
Does someone have an alternative solution or a fix for this issue in Visual Studio 2012?
Regards,
P.D.: BTW I already checked this post MSBuild error with linked files but like I said before changing the paths its not an option right now.
Try getting the Build Logs,
http://msdn.microsoft.com/en-us/library/vstudio/ms171470.aspx
it seems that csc task could not find the source file. One cause it you import the wrong file.
so you have to edit the project file via normal Text Editor.
I found a solution to this issue, when you linked the file, you relative path is recognized by msbuild and go back from there it become your path in a long path however you can change it in the project definition doing right click/unload the project/ and change the path from ../../../ to $(SolutionDir)/../.. until find the file to link, note: it's extend the character from 255 to 300 character.
Check that you have the latest version of the linked files from the other projects. Visual Studio will NOT automatically get them if they belong to another project.
Check that the linked paths are indeed correct. You can monitor what files VS.NET and MSBUILD are trying to access with the help of the SysInternals ProcMon tool (filter on process names and filter out all successes)
If you suspect that the path length is the problem (this will also be visible in the ProcMon tool), you can try to shorten them by linking to the absolute path (C:\X\Y\Z) instead of a relative path (......\Z). The location of the linked files can then remain unchanged.
My 2 cents to this problem... In my case, I had a file created in one project (i.e. ConfigModel) and I had a link to this file in another project but when I renamed the file ConfigModel in the first project to LoginModel for example, it didn't rename the link in the second project causing this error to occur.
I know that i did this question a while ago but for what is worth, The approach that we finally went for was:
Locating the files that were reported as too long.
Reduce the full path length of those files, by reducing the length of the name and/or
the length of the container folder or reducing the folder nesting
level. Therefore reducing the full path length.
Update the links of the changed files (re-linking) on the dependant projects.
This solved the problem with Visual Studio 2012 on developers workstations and on our CI/Deploy servers that used MSbuild.
For my scenario this approach was less risky,and implied less effort than moving complete projects/solutions to reduce their folder nesting level or reducing the folder names, and have to update all the references of the dependant project/solutions.
Ok, I hit this and solved it today. I found it by following a msdn tutorial (https://msdn.microsoft.com/en-us/library/ms379563%28v=vs.80%29.aspx) and here's the command that broke for me:
csc /t:library /out:MyCodeLibrary.dll simpleType.cs
Giving me the message
error CS2001: Source file 't:librabry' could not be found
Which worked after changing the original command to the following:
csc /target:library /out:MyCodeLibrary.dll simpleType.cs
I'm not sure why the short version of the /target flag causes this error, but I've not found anywhere else online noting this cause specifically so I wanted to record it here.
This problem arose for me when I reverted to an earlier version of a git repository. Apparently I didn't add the project file to the repo so when it reverted it didn't revert the project file also. What I did to clear it up was to exclude the missing .cs file from the project by clicking on the missing file in the project Explorer. It was easy to find since it was marked with a warning triangle. Then rebuild the entire solution.
Verify whether the files mentioned in the error do not exist in the corresponding folder.
If their non-existence is intentional, edit the .csproj files and remove the reference for those files.
Build again.
I inherited this issue from a project somebody else was working on, in my case was a .cs file supposed to be generated by an Entity Framework .tt template, but for some reason it wasn't, so the compiler was going all CS2001 about that. I had to update the template and manually run it, everything worked after that.
I am developing a SharePoint 2013 solution using VS 2012, the solution has a licx file. I get a compile time error and a warning.
Error: The specified task executable "LC.exe" could not be run. The filename or extension is too long
Warning: The command-line for the "LC" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "LC" into multiple calls with fewer parameters per call.
I have tried the lc.exe.config has <startup useLegacyV2RuntimeActivationPolicy="true">
I also tried moving the solution to "C:\", was earlier in the Projects folder.
I am still unable to resolve this error.
There is MS Support workaround:
when you build the project , delete the Licence file from the project
everytime you get this error , just delete the licence file
https://connect.microsoft.com/VisualStudio/feedback/details/779433/lc-exe-task-command-line-too-long
You will be able to save a lot on the path length by making a shortcut to the specific .NET version you use (in this case 4.5.2). Here are the steps;
run command line as Administator
Go to C:\ in command line
mklink /J net452 "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2"
Go to VisualStudio
Open project properties
Look into References tab
Click on "Reference paths" button and add path "C:\net452"
Rebuild project
Deleting licenses.licx file is not a solution. It will give you error at runtime if you are using third party control which need licenses.
LC.exe takes argument as licenses file with full path, if argument is too long, it throw error.
So keep the file name and path shorter length, it will compile and work.
Deleting licence file did not help me. I end up deleting the "licenses.licx" under the Solution Explorer -> Properties group
Surly that helps
This issue is fixed in VS2017 as per this GitHub checkin: https://github.com/Microsoft/msbuild/commit/e49717c727c3cab4db466bcb0a5abb624a8156bb
I believe the version is full release version is VS2017 Update 2.