Facing an issue with IS LE 2012 Spring & 2013 LE as well. I have VS 2012 solution with one common project (A) and several projects (B, C, D etc..,) referencing the common project. When I add a IS setup project and include project B's primary output, a setup file is created with project B's output and also project A's output. This is perfectly fine. But when I starting adding different folders within the same setup project to include project C & D's output, the output of the common project is copied to ONLY one of the projects whereas the expected behavior is to have the common projects output to all the projects that are referring it.
When I remove the project that has project A's output from setup and build again, project A's output magically appears in some other project's output. It appears that IS has some sort of flag to the files that needs to be copied and ignore the file once it is copied to one location?
The dependency scan on each project's output seems to show all the files correctly but misses them when it is copied over. I even tried adding the common project's (proj A) primary output to all other projects that are referring it but still the assemblies are not copied over.
Any suggestions? (apart from uninstalling InstallShield to make effective use of my hard drive space)
Related
I have a Visual C++ for Linux project in VS2017 that I'm building on a Raspberry Pi running Raspbian. This project consists of a single source file (main.c) and an image (test.jpg). When building the project, I want the image file to also be deployed to the pi, so that the code in main.c can do something with it locally. However, I can't figure out how to do this
The image file's Content property is set to True, as is Included in Project. In the project properties, under Copy Sources, Sources to Copy is set to "#(SourcesToCopyRemotely)" and Copy Sources is set to "Yes". However, when I build, only main.c is copied to the Pi, and the compiler output is just a single .out file. I hoped to also see test.jpg there, but alas.
This article mentions that #(SourcesToCopyRemotely) defaults to all files in the project. However, when I evaluate the value of #(SourcesToCopyRemotely, it evaluates to just "main.c".
How do I make sure content files in my projects also end up in the build directory, along with the .out file? Preferably without having to manually enter each filename in a post-build step.
It turns out this is a bug in VC++ for Linux. A workaround, currently, is to use Additional Sources to copy. There's a caveat though: it doesn't work with remote paths that start with ~. So you can't use $(RemoteRootDir) if the Remote Build Root Directory setting is set to the default of "~/projects".
I've currently got Remote Build Root Directory set to "/home/pi/projects" and for each file I want to copy to the build directory I set Additional Sources to Copy to "[filename]:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$Configuration)/[filename]". For instance:
firstimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/firstimage.png;secondimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/secondimage.png
Right-clicking on the non-source code file to open it's properties page and flagging as Content in the General tab will cause the file to be copied to the remote. There is no need to add anything to the Copy Sources tab. The Copy Sources page of the project properties must show the default of #(SourcesToCopyRemotely). And when you edit this setting the macro should show an expansion with the additional files included.
I have found that it necessary to refresh the macro by clearing Source to Copy and then restoring it to the default after you have marked the additional files as content.
I have encountered problems when the additional files are not in the same folder as the C++ source files on the Windows host and/or you want to put them somewhere else on the remote. There are several open issues on the VCLinux GitHub site like this one so it will be worth reporting any problems you have on there.
[VCLinux 1.0.6 on VS Pro 2017 + Debian Jessie remote]
The "Pre-Build Event" section of the project properties offers "Additional Files To Copy". Addressing my file there (relative to the solution) showed following in the output when building:
Copying file 'C:\myfilepath\resource.png' to '/home/pi/projects/myproject/resource.png'
It is possible to move the files to the final destination then with Remote Post-Build Events (mv source destination). Not the most elegant way, but the first thing I got working..
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 2 projects that are structured somewhat like:
FolderA
|
\--> Project1.vcxproj
FolderB
|
\--> Project1.vcxproj
The two Project1s are actually different projects.
When I right-click on my solution and Add -> Existing Project, I get the following error.
The solution already contains an item named 'Project1'.
Given that I can't rename the actual project files and that I want them both added to the same solution, is there any way I could do it?
I've tried many things:
Renaming the project file in Visual Studio.
Deleting the .suo file and restarting VS.
Editing the .sln/.vcxproj files using a text editor (but there was nothing relevant that I could find).
All of the above resulted in the same error.
I would think that since the project files are in separate folders, VS would treat them as separate projects, but there must be something I'm overlooking.
The problem occurs when you have two project files with the same name (not projects with the same name, but project files). In your case they are Project1.vcxproj and Project1.vcxproj. Therefore, you have to rename one of them (and do not forget to rename the corresponding Project1.vcxproj.filters file) and only after this add this project to the solution as an existent project.
Maybe the problem can be solved somehow else, without renaming the files, but I do not know how.
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'm developing application for GNU/Linux using gcc 4 and cmake to manage compilation process. I found that is has no problems when there are two files with the same name but in other directory and namespace like this:
.
|-- gfx
| |-- Object.cpp
| `-- Object.h
`-- logic
|-- Object.cpp
`-- Object.h
First Object class is in Gfx namespace and second in Logic namespace.
Then I've tried to compile this project using Visual C++ 2008 Express Edition. Linker threw several errors about non-existing implementation of Gfx::Object class. After few checks I found out that:
Visual C++ is tracking two of Object.cpp files
When change occurs in first or second file the recompilation of Object unit is queued
It always recompile only the second Object.cpp regardless of which file was actually modified
I also found out that Visual C++ don't allow to create two classes with same name.
Is there a solution for this? I don't really want to refactor quite big part of code.
Both Object.cpp files will be compiled to Object.obj. Into the same directory. In other words, the last one that is compiled will overwrite the Object.obj of the first one. Yes, the linker isn't going to be thrilled by that, you'll get multiply defined symbols since it links the same Object.obj file twice.
The fix is easy, right-click one of the Object.cpp files, Properties, C/C++, Output Files. Change the Object File Name from $(IntDir)\ to, say, $(IntDir)\$(InputName)2.obj
The problem is that by default VC++2008 places all the object files into a single output folder, so the existence of the first object.obj file satisfies the dependency for the second so it is not compiled; and even if it were, it would overwrite the first one.
What you need to be able to do is make the intermediate directory setting dependent in the file being compiled. However I have tried setting it to $(InputDir) and various other combinations, but could not succeed in achieving a configuration that works, although it may be possible. The available macros are documented here.
Failing that you could use a "makefile" project, and manage the build with make, nmake, or cmake or whatever, since there is nothing fundamentally wrong with what you are doing (even if it is ill-advised), it is just that it is not easily supported by the IDE.
This has already been answered, but I also want to add Visual Studio 2010 will automatically put the two .obj files into different directories if there is a conflict, based on my experience with Beta 2.
EDIT: Uh oh, this is wrong! The real answer is that CMake was automatically doing this for me.
The accepted solution is not optimal because it does not scale.
In Visual Studio 2010, I set
Properties -> C/C++ -> Output Files -> Output File Name
to
V:\%(Directory)$(PlatformName)_$(ConfigurationName)_%(Filename).obj
for OBJ files to end up next to the sources assuming the project lies on drive V (no idea whether there is a macro for it, yet).
Not optimal, either - but at least I can easily fork subsystems of many source files without getting tenosynovitis.
By the way: $(InputDir) refers to the solution/project directory and will cause the same problem in another directory.