Recently, I changed a Visual Studio solution that contains about 140 projects to output all the library project's output files to the same bin folder in the solutions root directory.
After changing all the project's output directories and doing a re-build, I noticed some projects output both in the correct bin\\{platform}\\{configuration}\lib\ folder but also in the bin\ folder. The files appear to be the exact same. Only the DLL and PDB files go into the bin folder, the configuration file and XML documentation file do not. If I do a clean, the files in the bin folder do not get deleted. I can build the projects one at a time and some do this, some don't. If I build using MSBuild from the command line this does not happen.
Is this expected/normal? I built with the MSBuild output set to diagnostics but there is no mention of the bin\ folder alone, all mentions of the bin folder include the correct platform, configuration etc..
Related
What I want to achieve:
A clean build directory generated by CMake for Visual Studio, with build system targets like ALL_BUILD and ZERO_CHECK and additionally created directories like Visual Studio's x64 physically located somewhere else than in the root directory.
What I have tried:
As the accepted answer at CMake: How do I change properties on subdirectory project targets? points out, all I have to do is activating the use of folders with the following line.
set_property(GLOBAL PROPERTY USE_FOLDERS TRUE)
The problem:
This does only create a folder in the visual studio project structure for CMakePredefinedTargets, not in the physical filesystem. And the x64 directory keeps untouched too!
So what do I have to do?
Let's say I have a solution called MyFirstSolution and inside I have project with name MyFirstProject. Inside that project I'm installing nuget packages like Dapper, EntityFramework etc...
How things should work:
packages folder should be created into the folder MyFirstSolution and inside should be downloaded and installer all nuget packages referenced into the project.
The problem I'm having is that the packages folder is not created and the nuget packages are downloaded one level above the MyFirstSolution folder into some folder called XYZHelper.
When I download a solution from some repository nuget packages are restored to that same folder, not to the solution itself and references in csproj file says that they should be in solutionFolder\packages so all of my projects don't build.
If I copy the packages manually to the folder that they should be, it's all good but after every build a copy is made into that XYZHelper folder.
I don't have any postbuild events or anything like it configured into the projects. It is something with the visual studio I guess, but I can't figure out what.
How things should work: packages folder should be created into the
folder MyFirstSolution and inside should be downloaded and installer
all nuget packages referenced into the project.
Hi Stdfan, not sure about your VS version. But for VS2015 and earlier versions, the nuget packages are controlled by packages.config file. And things should work like what you mentioned.
But for VS2017 and VS2019, they have two methods to manage nuget: Packages.config and PackageReference. And for PackageReference format, the packages are stored in C:\Users\xxx\.nuget\packages. So if your vs version is VS2017 or VS2019, you can try if changing the format to PackageReference help resolve this issue.
The problem I'm having is that the packages folder is not created and
the nuget packages are downloaded one level above the MyFirstSolution
folder into some folder called XYZHelper.
Direction1:
Like zivkan suggested,I also think something affects the restore process.Normal for Packages.config format, the folders would be stored in packages folder. But according to
this document, we can customize nuget.config file to control nuget behavior. So please check locations where nuget.config exists,there might be some changes in the nuget.config for computer or some settings in nuget.config for users which causes this issue.(The nuget.config for user won't exist unless we create it there)
Direction2:
When I download a solution from some repository nuget packages are
restored to that same folder
As the restore process is invisible in build output, so there is possibility that the nuget restore works well, but something in build process move the content of packages folder into XYZhelper.
Check customize your build. Please check your directory structure for the Directory.build.xx file, it can affect your build process if it exists in any folder of the structure: C:\xxx\lancel\source\repos\
I don't have any postbuild events or anything like it configured into
the projects. It is something with the visual studio I guess, but I
can't figure out what.
This is not about VS normal settings. I think some custom file causes this issue(no matter nuget.config or directory.build.xxx), and please check if you've installed any third-party software or vs extension. Try close vs, delete the .vs, bin and obj folders and then run vs as safe mode.
Target folder of nuget packages can also be set using the envirenment variable NUGET_PACKAGES.
And you can do this in your existing project-file like this:
<Project Sdk="Microsoft.NET.Sdk">
...
<Target Name="NugetPublicfolder" BeforeTargets="PreBuildEvent">
<Exec Command="SET NUGET_PACKAGES=C:\MyProjectA\libraries\"/>
</Target>
...
</Project>
Now when you build/publish the project the libraries will be placed in C:\MyProjectA\libraries\
Actually the nuget packages are first downloaded to the socalled http-cache folder (%userprofile%\AppData\Local\NuGet\v3-cache), where it will be extacted from to the above folder (which is called the globalPackagesFolder folder)
The solution packages folder can be changed with a nuget.config (the setting name is called repositoryPath). So, check for nuget.config files that might be setting this value. You can get an exact list of nuget.config files used by a restore by downloading nuget.exe from nuget.org/downloads and running nuget restore MyFirstSolution.sln. Near the end of the output it will list every nuget.config file that was read.
When there is no config file that changes the solution packages folder (repository path), it always defaults to a subdirectory named packages in the same directory as the .sln file. The only way I know of to change this location for packages.config projects is with a nuget.config file, so I feel confident you should be able to solve it by finding the right config file.
I'm working with ASP.NET MVC 4 in Visual Studio 2010 for the first time, and I control source code with SVN. I used to work with MVC 1 in Visual Studio 2008, where I had my own filter for svn:ignore
*.pdb
*.exe
*.dll
debug/*
release/*
*.user
*.suo
obj/*
bin/*
obj
bin
VSMacros80
Thumbs.db
_ReSharper.*
but it doesn't apply in the same way now because the project has some new folders, as the packages folder, and I don't know which of them must be versioned.
About the packages folder, should I include it the repository or this folder must be ignored? What other folders or files should I ignore?
It sounds like you are using NuGet and the packages folder is the NuGet packages folder. You can commit this to source control if you do not mind adding several large but infrequently changing binaries.
Alternatively, you can omit it from source control and configure NuGet to download packages on each build if developers and the build machine are to download it as required. This also runs the danger of someone downloading a newer version and causing conflicts.
As for other files to exclude form source control, see What .net files should be excluded from source control? and For a .Net project, what file extensions should I exclude from source control?.
I need to send the solution which consists of 2 projects by email.
Can I delete ipch folder?
Yes, that's the folder used by the IntelliSense parser to store precompiled header files. It will be rebuilt on the receiver's machine. More in this answer. Use Build + Clean to avoid having to look at too many of them.
There is an answer in the MSDN support forums:
I'm not only a C# moderator but also a C++ user :} The ipch directory
and the many, many new files generated by the compiler can be safely
deleted. In fact they should be deleted (and probably are) for clean
builds. I teach a C++ college class myself and here is what I require
my students to do. In the solution folder delete all bin, obj, ipch,
debug and release directories.
Delete any .suo files
Delete any .user files
Delete any .ncb files
Delete any .sbr files
Delete any .*log files (for VS 2010)
Zip up the entire solution directory for submission. This ensures
that the solution and project structure remain intact.
The answer link:
Is it safe to delete "ipch" folder - Pre-compiled headers
As mentioned here: How to change ipch path in Visual Studio 2012
Change to "always use fallback location" in this way this directory does not get created inside your solution but the system temp directory is used. This worked for me.
You can delete these files with this simple windows command:
project_folder> del *.log *.ipch *.suo *.user *.ncb *.sbr *.vc.db *.obj /s /q
I'm trying to use OpenCv 2.2 in Visual Studio 2010.
I've configured everything by instruction:
http://opencv.willowgarage.com/wiki/VisualC%2B%2B
and by instruction from the book:
So I've added all /lib and /include paths.
When I build project, it compiles and before starting app, VS displays an error message that opencv_core220d.dll is missing.
This file is in C:/OpenCV2.2/bin as all .dll files. If I add this file to my working directory - it will be fine. Then VS displays error about every .dll file that I added in Linker-Input configuration ( but with .lib extension ).
So, if I add all .dlls file that I've added as .lib in Linker configuration - to my working directory, project will start.
But why? Why VC doesn't see OpenCV2.2/bin folder? Where is this pointed?
Because it doesn't know to look there by default. However, it does know to check the current directory for the DLLs.
You can tell it where to look by adding C:/OpenCV2.2/bin to your Path variable, or if you would rather not muck up your global Path you can set the Environment variable local to the C++ project.
I think that is the syntax for appending to the Path in VS2010, but I'm not sure, so Google it if that doesn't work :)