I have a project in Visual Studio 2019 and I met a situation, when there were files with Build Action set to Content missing on a disk but present in project (listed in .csproj file). My local build finished successfully, but when I checked this code to TFS, build on the server failed because of missing files.
I wonder if there is any instrument to force VS compiler to look at Content files and check if they exist.
Thanks in advance for any advice.
Maybe you should have a look at the Visual Studio Plugin Show Missing Files 2019.
Disclaimer: I do not have any experience with this plugin myself, it just seems to fit your situation.
Related
I have a large solution of dozens of projects. Since yesterday (and for no good reason that I can find) the projects are refusing to build, with Visual Studio's build output window simply stating (eg)
1>------ Skipped Rebuild All: Project: Api.Models.Common ------
There are already a few similar q/a's here about the reasons why VS may decide to skip a build (Configuration not set to build, or set to build wrong target). I'm not interested in guesses as to why this isn't building. I'd really like answers to help me diagnose this, and have Visual Studio tell me why it thinks it can skip the build.
Is there a way to have VS generate anything more detailed than Skipped rebuild for example? It must be calling msbuild under the covers right? So can I have Visual Studio pass additional parameters to msbuild so that it generates diagnostic log output?
(For what it's worth - calling msbuild from the command line builds the projects as expected, so it seems like my issue is something quirky that VS is doing).
I'm using VS 2017 - 15.9.4
If you have any unload projects, you must load it or you remove it in solution.
Note: My unloaded project was the result of a permission issue. VS warned that a project was configured to use IIS. To run the project with IIS required launching VS as an administrator.
This was happening in my solution with Visual Studio 2019. I just migrated my applications from .Net Framework 4.6 to .NET5, almost all the projects were not building, it gets always skipped. The reason was that after the migration the tool upgrade assistant was not setting the Target Framwework as in the preceding image (Right-click on the project and then click on Properties).
After setting it to the right framework, in my case, it was .NET 5.0, the project started to build.
We are facing an issue related to .PDB files for Website application and here is the details:
If we publish the website from Visual Studio 2017 (right click on website and Publish) I can able to see .PDB files.
We tried with command line query also but its not able to publsih the .PDB files.
Also we are not able to publish the .PDB files as part of the TFS 2018.3 build (vNext build).
FYI, I have followed all the suggestions mentioned in other post (Visual Studio 2012 Website Publish Not Copying .pdb files) but it doesnt worked for me.
The reason for asking different questions is, the other post was related to Visual Studio and this is related to TFS 2018.3.
Thanks,
Sam
I can able to resolve the issue by adding below MS arguments in vNext Build,
/p:DebugType=pdbonly
/p:OutputPath="$(Build.SourcesDirectory)****\Bin"
Thank you
I have a Website Project in Visual Studio 2010 along with a Class Library Project. When I try to build the Solution from Visual Studio 2010 it builds successfully but fails in TFS 2010 Build. I have some custom .dll files added to website and it throws error in my class that following method is undefined. The same thing builds 100% ok in VS 2010. Earlier I had a different project structure but since then I even changed the project and file structure following this article on MSDN for TFS 2010 Version control.
The Build fails and it drops a log file in the drop folder.
EDIT
Some of the errors in the log files are related like this.
error BC30451: 'AutoCompleteExtender' is not declared. It may be inaccessible due to its protection level.
error BC30002: Type 'IFileNameGenerator' is not defined.
These errors don't show up in VS2010.
This problem could occur when you are referencing a DLL from your solution that is not installed on the server or is somewhere in your project structure but not included in your TFS source control.
If you look at your build summary in TFS you have a 'View Log' option that shows more details. You can also specify a log verbosity in your buil;d definition template. Increasing this could give you some hints.
Read the log file. Searching for :error usually helps
Had the same problem with a contract in a nuget package. Turns out it was a bad merge. Compare the csproj/vbproj files and see if there are any differences in package versions
I've got a project that used to work in VS 2008 that has a custom build tool for each file (runs a batch file) that used to work as expected.
On upgrading to VS 2010 when you build the project it only builds one of the source files, then stops without errors.
If I compile each file individually they work fine. If I repeatedly build the project it builds each source file in turn until they are all done.
I suspected the conversion process so re-created the project from scratch and it had the same issue..
any ideas?
Thanks
Trev
Apparently, this is by design in Visual Studio 2010:
http://connect.microsoft.com/VisualStudio/feedback/details/572435/only-1-custom-build-step-is-executed-in-a-build
There is a little more discussion here:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/3de31464-46fb-40a3-a666-496355b1b6be/
I'd love to have a work around for this.
For two of my VS 2005 C++ projects, VS wants to write to the .sln file when I build the projects. I have got a number of other VS 2005 C++ projects where this is not the case. It is a problem as due to the fact that we have ClearCase source control integrated with our VS 2005 installations and when we try and run an overnight build via batch files, the build pauses as a ClearCase check out dialog box is displayed.
Looking at what VS is changing in the .sln files, it is the second GUID on the project line.
Before building:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{A2AF232A-7F27-4340-81D5-8ABFD10994D2}"
After building:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{67BE85B7-3234-484E-88FB-4F0E42096583}"
Any help gratefully received. I am new to VS 2005, as we have only recently migrated from VC++ 6.0, so apologies if I have missed something obvious.
We are running VS 2005 Professional Edition, with SP1 installed.
Regards,
Greg.
I had similar problem. It seems that when converting projects from old versions of VS (like 6 or 2003) VS 2010 is not adding Project GUID to the .vcxproj file. Because of that when you open solution including such project VS will recreate GUID for such project, and will change .sln file but will not change .vcxproj file. So another time you open such solution the situation will be the same and the .sln file may change again.
See this: http://connect.microsoft.com/VisualStudio/feedback/details/586258/missing-projectguid-in-vcxproj-files
I am guessing here, but it looks like some changes have been made to the InterCommClientB project(project, not the files in the project). When this happens the sln is updated, in this case only the project GUID.
My best guess to resolve this issue would be to manually build the solution and then checkin the changes. This way the sln file won't change on build.
My second best guess is that you already made this changes at your computer and it is working fine, but you did not get lattest version on the pc where you do the night build .
This might be totally out there - but sometimes Visual Studio fails to check-in a Solution file when it's been modified and while the Solution is open in Visual Studio. Try closing Visual Studio, and only then committing the Solution file.
If it isn't that, there might be some other agency causing the Solution file to need to change the GUIDs its using. In one instance, I was using .NET tools from National Instruments, and they has a licensing scheme that would trigger that sort of action (modification of extraneous files for not good reason) whenever I went to do a rebuild.
Please take a careful look at the output from the build (in the log, or the output window) - you may find some further clues there!