Not sure if this is the correct place to ask this but there have been a lot of visual studio questions in the past here.
I am currently creating a lot of npm packages in a solution and as part of the package, I have to create a package.json file.
Once I save the file, it creates a node_modules folder and downloads all the dependent npm packages to it. Now I have got azure dev ops to ignore these files so they aren't checked in by adding the node modules folder to the list of ignored folder names, but I also want to exclude them from my project so that it doesn't lock my computer every time it tries to write all the file names in to the .proj file.
Is there a way to automatically tell the project or solution to auto exclude this folder - like a solution ignore file I can add the name to?
Or is there an option somewhere that folders that aren't created through vs, aren't automatically added to the project - this is how my earlier versions of vs worked - new folders not created through vs would have to be manually included if you wanted them in the project / solution
Ok this is due to the project type that I used when creating the project - I created it as a .net core project and that seems to add files by default and only exclude them if you tell it to, if I change this back to a .net standard project, it works as I would expect - only includes files you drag into the project or tell it to include
Related
I have used Specflow/MSTest to create a test suite. I need to be able to package this so that a third party can run the tests etc.
I can use vstest.console.exe to execute the features/scenarios using a number of .runsettings I have.
Problem I have is how to copy the files from the Microsoft.TestPlatform nuget package to my project output folder (whether same folder, sibling folder whatever; that is not an issue, I can work that out no worries). I just can seem to work that out.
I have read a number of posts, on SO and elsewhere, with folk asking same/similar questions but I just cant repro how to do it.
Have tried editing the project file to copy PackageReference 'always', using the 'None' element etc but just can't seem to get it. Microsoft.TestPlatform is used extensively so I'm guessing that i'm missing something simple here; I just cant get Google to be my friend in this instance.
So, if my .NET5.0 (framework may be irrelevant) project has a Nuget Package referenced but is not referencing it in code anywhere how do I instruct Visual Studio to copy the files from that package to whatever folder I need them to go when I do a build?
Try to modify the package management to "Packages.config", it will auto copy the dlls to output folder.
If you want to copy dlls to other folder, you can use xcopy command in post-build event.
dotnet publish is the command you're looking for
dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output includes the following assets:
Intermediate Language (IL) code in an assembly with a dll extension.
A .deps.json file that includes all of the dependencies of the project.
A .runtimeconfig.json file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type).
The application's dependencies, which are copied from the NuGet cache into the output folder.
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish
I noticed that for VS Projects controlled with TFVC, debug folders are ignored naturally without having to create a .tfignore file to exclude them. However, I have a legacy project that seems not to follow this behavior and I am unable to fix it because I don't know who's responsible for that behavior in the first place.
Can you explain why debug folders are ignored naturally without having to use a .tfignore?
There are already pre-defined list what files will be excluded by TFS if there is no custom .tfignore specified/present on the system.
You could refer to the "LocalItemExclusions.config" file under the path "C:\Users\youraccount\AppData\Local\Microsoft\Team Foundation\x.0\Configuration\VersionControl" folder and open".
(There may several folders named like 1.0, 2.0, 3.0, you need to make sure open the folder that match your TFS version.)
You could see that these folder and files types are ignored by default and they are defined in that file.
<Exclusion>bin</Exclusion>
<Exclusion>obj</Exclusion>
<Exclusion>*.exe</Exclusion>
If those files still could not be excluded by default in the legacy project on TFS, as a workaround, you could manually add a .tfignore file in that specific project.
SOLVED The problem turned out to be that - for any reason - the one who added the project to TFS the first time, added the debug and release folders with it - either deliberately or his VS was miss configured - and hence, the VS will keep track of those files even if ignored by default (natural behavior).
In order to solve it, I had to delete those folders form the TFS itself and then get the latest version to get the local copies deleted as well ... later after building the project and having those folders created again, VS will not recognize them as new files/folders because they are ignored by default as mentioned.
I'm working on C++\CLI that someone else started. The solution is made up of 3 C projects and 1 C++\CLI project that uses them.
I've duplicated the C++\CLI project and change it name and ProjectGUID property in the vcxproj file.
The problem is I still get the error listed bellow.
How can I fix this?
Warning 1 warning MSB8028: The intermediate directory (Debug\) contains files shared from another project (my_project.vcxproj). This can lead to incorrect clean and rebuild behavior. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppBuild.targets 388 5 seebo_prod_line_tool
Same problem here, solved by
Deleting all Debug\ and Release\ folders (there were more of them in subfolders where I didn't expect them)
Changing the .sln file manually to fix the name of a referenced C++ project (.vcxproj) which apparently was not renamed when renaming the project in Visual Studio
My suggestion is to make sure the intermediate directory for each project is different (as suggested by someone else earlier.)
To do this,
Open the project's Properties dialog
Under Configuration Properties, select General
Make sure the Intermediate Directory for this project is unique to this project.
I ran into this problem because using previous versions of Developer Studio I had a host of companion projects but wanted all of them to put their output in a common "Release" folder. Inadvertently I had set the same common release folder settings in the Intermediate Directory path for some of the projects (but not all).
I found you can disable these types of warnings by added the following to the project file:
<PropertyGroup>
<IntDirSharingDetected>
None
</IntDirSharingDetected>
</PropertyGroup>
I myself also encountered this kind of warning.. But I obtained this in a different situation, I renamed my whole solution/project via IDE and thus making another copy of an entirely different project. So what I have here is a total of two projects sharing one common resource, source and header files. This makes this warning pop up.
I fixed this by deleting the files associated with the project, which you renamed previously. Delete these INSIDE the DEBUG folder. In your case, try deleting all 'my_project' files, regardless of any file extensions because it shares resource files to your duplicated project.
The cause of this problem is copying an intermediate directory that was created by Visual Studio, and that already contains files from a previous build. It is not a problem in the project settings, but a problem caused by the existence of unexpected files from another project. In this context the warning is benign, but annoying.
The minimal solution is to find and delete each such file. The simpler solution is usually to "super clean": delete every directory created by Visual Studio (with names like bin, obj, x64, x86, Debug, Release and so on), and allow VS to re-create them during the normal build process.
I have experienced this problem as well, and for me, the cause was that there were multiple libname.tlog directories inside the intermediate build folder. These directories contain libname.lastbuildstate files that I assume are used for dependency checking. Doing a Clean of the project I don't think will delete these extra directories.
So in this case I was able to delete the libname.tlog directories and build again. I don't know how it got into the state of having multiple directories inside each intermediate directory -- perhaps they were created when I updated the VS version.
I have two projects in one Visual Studio 2008 solution. I'd like to use the primary output from one of the projects as an embedded resource in the other, but for the life of me I can't find any way to accomplish this.
If I simply add the output file as a resource, then it doesn't seem to change when its source project is rebuilt. I even have the project dependencies/build order set up properly and this does not seem to help.
Anyone have any hints for me?
Thanks!
the best option is to "reference" the other project as if it were a class library.
that way you make sure the whole references tree is copied to your output dir.
When you add an existing file to a project, Visual Studio copies the file into the project's directory.
Any subsequent changes to the original file are ignored.
There are two workarounds:
Add a post-build action to the first project that copies its output file to the second project, and edit the dependencies so that the first project is always built first.
Add the output file to the second project as a link (Click the down arrow next to the Add button in the open dialog).
This will reference the file from its original location without making any copies.
Set the output directory of the project that generates the resource to point to the resource directory in the project that uses it.
If that's not possible for some reason, use a post-build command (also available in the project settings) to copy the file there.
I have a Web Setup project in VS. I'll be switching to WiX, but that's in the future and currently I need to solve the following issue.
I need to exclude some common dlls from the project. So I build the project, VS updates the list of Detected Dependencies. I exclude them and the setup builds. I check the file list with Orca and the files are not included in the installer.
But when I clean my output directory, reload the solution and do the build, some of the dependencies do not show as excluded! And so they end up in the MSI. (This is what is happening on the build machine).
I think that the problem might be with the fact that these are second-level dependencies:
my app -> NHibernate.dll -> Antlr3.Runtime.dll
(Antlr dll ends up in the MSI).
Is this a bug or am I missing something?
I found this page on msdn that has a work-around for the Exclude flag being reset to False:
Previously excluded files are included again when the solution is re-opened
When you exclude a file from a Setup project, you may see that the file is included again after you close and re-open the solution. This may occur if there are two copies of the same DLL file from two different source locations.
To work around this error, change the Copy Local property on one of the files:
In Solution Explorer, click on the DLL reference that you want to remove.
On the View menu, click Properties Window.
Change the Copy Local property to False.