I have a project in Visual Studio and want all files generated during build under the build\ subdirectory.
I set all output options I could find but there is still a Debug\ folder created with the files: projectname.dll.recipe and subfolder projectname.xxxx.tlog which contains .tlog and .lastbuildstate files.
I know the .tlog files are from the MSBuild File Tracker, know idea what the .dll.recipe is.
How can I set the output directory for those files to $(OutDir)?
You can try the following steps:
Function 1
Open your project in VS IDE and then right-click on the project Properties-->Configuration Properties-->General--> change Intermediate Directory to ..\$(Configuration).
Then, rebuild your project to get what you want.
Function 2
1) add a file called Directory.Build.props in your solution folder like this:
2) add these content in the Directory.Build.props:
<Project>
<PropertyGroup>
<IntDir>..\$(Configuration)\</IntDir>
</PropertyGroup>
</Project>
3) close VS Instance, delete any Debug folder in your solution folder.
Then restart VS(enable the function of the Directory.Build.props) to open your solution to build again and the files will be under the $(OutDir) path.
Visual Studio 2017 / ASP.NET Web Application solution.
The default folder structure is as follow:
What I want to achieve is keeping everything (including packages) inside the WebApplication1 folder (except WebApplication1.sln file).
I know about NuGet.Config but unfortunately it seems mandatory to place this file next to the .sln file. I would have preferred to place this file inside of WebApplication1 folder. I would like to have ONLY ONE file outside of the solution folder: the WebApplication1.sln file.
I know about NuGet.Config but unfortunately it seems mandatory to place this file next to the .sln file. I would have preferred to place this file inside of WebApplication1 folder. I would like to have ONLY ONE file outside of the solution folder: the WebApplication1.sln file.
I understand your requirement, you want to have only WebApplication1.sln file outside of the solution folder. But if you are using nuget.config to change the location of packages, this nuget.config file will be placed in a folder outside the solution folder, which is not what you want.
To resolve this issue, you can put this nuget.config file outside the solution folder, which is not necessary to put this file next to the .sln file, for example, you can put this file in the root directory of the C drive with following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="C:\Users\<UserName>\source\repos\WebApplication1\WebApplication1\packages" />
</config>
</configuration>
Then close your Visual Studio and delete the packages folder in the solution folder, re-open the Visual Studio and open the your solution, right click on the your solution, select restore the nuget packages, all the nuget packages will be place inside the solution folder and the only file outside of the solution folder is the WebApplication1.sln file:
Note: This method has its own limitations, we have to use absolute path in the nuget.config file and this setting will still be work for other solutions.
Besides, you can try to use PackageReference instead of packages.config in project files. With PackageReference, your packages are point to the global package folder C:\Users\<UserName>\.nuget\packages, so that we do not need add a nuget.config file to change the package folder.
To use the PackageReference, go to the Tools->NuGet PackageManager->Package Manage Settings:
Hope this helps.
My understanding of why the visual studio put the package folder next to .sln but outside WebApplication1 folder is, WebApplication1 is a project in the WebApplication1 solution. But one solution can contains multiple projects. In your case the project name happens to be same as the solution name(due to when you create this project and solution in vs). So if you have multiple projects in this solution but want to share some nuget packages, then it make sense for the package folder to be outside the project folder.
Thant's my understanding for why vs has this default setting. Hope that helps.
When I use the option Publish... selecting as target the file system in Visual Studio 2015 it compiles the code, do the XML transformation in the Web.config files and copy the files to the folder I specified.
It does not copy any *.cs file as expected since it is compiled.
Something that I don't understand is why it publishes the Nuget Config file (packages.config), after all, the files needed are already in the bin folder.
I found this question that says how to avoid but not the reason they decided this file would be usable on the server.
Can I stop VS from publishing packages.config?
Anyone know why packages.config end up in the publish folder?
The default value of working directory in visual studio property sheet is $(ProjectDir). If we have some dependencies (e.g., config files or libs & dlls), we have to put them in the working directory.
Since the default $(ProjectDir) is different from the output directory (namely $(TargetDir), folder where the EXE file resides), we have to copy the dependencies to the output directory if we run the EXE file by double clicking it.
So I'd like to change my working directory to $(TargetDir), in case I have to copy my dependencies twice. The question is: Why is the default working directory set to $(ProjectDir) but not $(TargetDir)? Is there any good reason for visual studio to do so?
I have a Visual Studio C++ project that relies on an external DLL file. How can I make Visual Studio copy this DLL file automatically into the output directory (debug/release) when I build the project?
Use a post-build action in your project, and add the commands to copy the offending DLL. The post-build action are written as a batch script.
The output directory can be referenced as $(OutDir). The project directory is available as $(ProjDir). Try to use relative pathes where applicable, so that you can copy or move your project folder without breaking the post-build action.
$(OutDir) turned out to be a relative path in VS2013, so I had to combine it with $(ProjectDir) to achieve the desired effect:
xcopy /y /d "$(ProjectDir)External\*.dll" "$(ProjectDir)$(OutDir)"
BTW, you can easily debug the scripts by adding 'echo ' at the beginning and observe the expanded text in the build output window.
The details in the comments section above did not work for me (VS 2013) when trying to copy the output dll from one C++ project to the release and debug folder of another C# project within the same solution.
I had to add the following post build-action (right click on the project that has a .dll output) then properties -> configuration properties -> build events -> post-build event -> command line
now I added these two lines to copy the output dll into the two folders:
xcopy /y $(TargetPath) $(SolutionDir)aeiscontroller\bin\Release
xcopy /y $(TargetPath) $(SolutionDir)aeiscontroller\bin\Debug
To do it with the GUI, first add the file(s) to the project: right-click the project, select "Add...", then "Existing Item", then browse to the file or files you want to add and click "Add". Next, tell Visual Studio to copy the file when you build: right-click the file you want to copy, select "Properties". You'll see a list of properties, including "Item Type". Change the "Item Type" to "Copy File". Hit OK and you're done.
Here's the file properties dialog:
Looking in the *.vcxproj file, the steps above add something like this:
<ItemGroup>
<CopyFileToFolders Include="libs\a.dll" />
<CopyFileToFolders Include="libs\a.dll" />
</ItemGroup>
I couldn't find any official documentation for <CopyFileToFolders>, but clearly it's supported or the GUI wouldn't use it. But, if you're doing it by hand and an undocumented item type makes you uncomfortable you can always use the well known but slightly more verbose <Content> type:
<ItemGroup>
<Content Include="libs\a.dll" >
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
<Content Include="libs\b.dll" >
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
Add builtin COPY in project.csproj file:
<Project>
...
<Target Name="AfterBuild">
<Copy SourceFiles="$(ProjectDir)..\..\Lib\*.dll" DestinationFolder="$(OutDir)Debug\bin" SkipUnchangedFiles="false" />
<Copy SourceFiles="$(ProjectDir)..\..\Lib\*.dll" DestinationFolder="$(OutDir)Release\bin" SkipUnchangedFiles="false" />
</Target>
</Project>
(This answer only applies to C# not C++, sorry I misread the original question)
I've got through DLL hell like this before. My final solution was to store the unmanaged DLLs in the managed DLL as binary resources, and extract them to a temporary folder when the program launches and delete them when it gets disposed.
This should be part of the .NET or pinvoke infrastructure, since it is so useful.... It makes your managed DLL easy to manage, both using Xcopy or as a Project reference in a bigger Visual Studio solution. Once you do this, you don't have to worry about post-build events.
UPDATE:
I posted code here in another answer https://stackoverflow.com/a/11038376/364818
xcopy /y /d "$(ProjectDir)External\*.dll" "$(TargetDir)"
You can also refer to a relative path, the next example will find the DLL in a folder located one level above the project folder. If you have multiple projects that use the DLL in a single solution, this places the source of the DLL in a common area reachable when you set any of them as the Startup Project.
xcopy /y /d "$(ProjectDir)..\External\*.dll" "$(TargetDir)"
The /y option copies without confirmation.
The /d option checks to see if a file exists in the target and if it does only copies if the source has a newer timestamp than the target.
I found that in at least newer versions of Visual Studio, such as VS2109, $(ProjDir) is undefined and had to use $(ProjectDir) instead.
Leaving out a target folder in xcopy should default to the output directory. That is important to understand reason $(OutDir) alone is not helpful.
$(OutDir), at least in recent versions of Visual Studio, is defined as a relative path to the output folder, such as bin/x86/Debug. Using it alone as the target will create a new set of folders starting from the project output folder. Ex: … bin/x86/Debug/bin/x86/Debug.
Combining it with the project folder should get you to the proper place. Ex: $(ProjectDir)$(OutDir).
However $(TargetDir) will provide the output directory in one step.
Microsoft's list of MSBuild macros for current and previous versions of Visual Studio
I had a similar question. In my project, there were couple of external DLLs. So I created a new folder in the project called "lib" and copied all the external dlls to this folder.
Add a reference to these DLLs.
Go to Project References>dll properties and change the following properties
enter image description here