I am using VS 2017, .net Framework 7, stylecop 5.0. I imported it in '.csproj' file of all projects, so that stylecop builds automatically when the solution is built. It does show stylecop warnings when i built the solution.
When i right-click solution ->click "Run stylecop", I get more warnings than when I build normally.
Why doesn't it show when i build normally? Am I missing any commands?
I used this:
Import Project="..\packages\StyleCop.MSBuild.5.0.0\build\StyleCop.MSBuild.targets" Condition="Exists('..\packages\StyleCop.MSBuild.5.0.0\build\StyleCop.MSBuild.targets')"
This is often due to Visual Studio being considerate. It will only compile source files that have changed since the last build. Therefore only the Stylecop issues in those files are reported. When you run Stylecop specifically it will assess all c# source files.
Try doing a rebuild rather than build and see if the numbers add up.
Related
I have a solution that contains both C++ and C# projects that is built in a nightly CI build on a remote machine. The build script checks out a clean copy of the source and builds both debug and release configurations of the solution using MSBuild and runs the test suite on each configuration.
About every other build, the release configuration fails to build properly. An analysis of the build log reveals that C++ Project Q, which depends on C++ Project D, tries to link before Project D is done. This error only happens for the release configuration on this particular build machine - the debug configuration builds without error. I have a separate nightly build process that runs on a separate machine where the release configuration is built with a similar script that uses MSBuild (it just does not run the test suite), and it builds the same source revision without issue. Multiple team members build the solution without issue either from update or clean checkout with one or both configurations, always from the Visual Studio 2019 IDE, on various operating systems.
Project Q is configured with Project D as a project reference and Project D is also listed as a hard-dependency for Project Q. As I mentioned, the build script is using MSBuild.
An additional item of interest from analysis of the release and debug build logs: The build of Project D is initiated differently between the two configuration builds. It is started by its own metaproject in the release configuration (as item 60, for instance), but started earlier (as item 44, for instance), by a different project in the debug configuration. Not sure why the dependency algorithm would run with such different results in the two cases since the solution and working source being built are the same.
Any ideas or suggestions would be appreciated.
Update: Inspection of differences between the release and debug build logs reveals some interesting facts. In the failure case I did a search for ") is building" in each log - should be an indication of how many projects were built, including metaproj entries. For the failure case, debug had 282 occurrences, whereas release had 175. For the success case, debug had 280 occurrences and release had a whopping 559! A similar search for "Done Building Project" yields similar results, only off by 1 or 2. That might partly explain the differences in build order between the solutions. I also need to check for conditional build entries.
Visual Studio 2019 Reference Project Not Built Before Dependent
Project Tries To Link in Release Configuration using MSBuild
It seems that project buid order was broken and Project D built later than Project Q which need the output content of Project D, so the whole build failed.
Not sure that if you use Project Dependency(Right-click on project-->Build Dependencies-->Project Dependencies), if so, only VS IDE Build Will recognize their build order while MSBuild command line will lose the relationship about them.
Besides, I wonder if your main project under Release mode references a dependency project under Release mode. If you did these, the build will definitely go wrong.
All of these above is that I think you made some changes to your project.
You could follow these steps:
1) I suggest you could try to use Project Reference and it will add these xml node in ProjectQ.csproj file to strongly specify build relationship:
<ItemGroup>
<ProjectReference Include="..\ProjectD\ProjectD.csproj">
<Project>{26c26cdd-a5e0-40c7-b0c9-4563f969424f}</Project>
<Name>ProjectD</Name>
</ProjectReference>
</ItemGroup>
Also, check if there are any conditions that distinguish between Debug or Release mode when referring to a project like this:
<ProjectReference Include="..\ProjectD\ProjectD.csproj" Condition="'$(Configuration)'=='Debug'">
If so, please remove that condition Condition="'$(Configuration)'=='Debug'" to make sure it is the same between Debug and Release mode.
2) close VS Instance, delete .vs hidden folder under solution folder.
3) check your CI Build and cloud build server and ensure that cloud parameters are consistent with other servers. And examine any of your xxx.csproj files to check if you have any other operations which causes this bahavior.
In addition, if necessary, you can share your xxx.csproj file and the build script with us to troubleshoot it.
I work in a project using Qt compiled with Visual Studio C++ compiler.
I noticed after migrating from VS2017 to VS2019 that when building the application, VS always find qrc cpp files as modified and try to rebuild them.
Is not happening for all projects though, only some unit tests.
Does someone notice this behavior?
I've had the same issues when upgrading from vc141 (2017) to vc142 (2019). It's old but the only post I found, so:
The difference in the toolkits is that in vc142 "Custom Build Tools" are now appended to include inherited values. If your project is configured to use a build tool projectwide by default (for example meta objects from QTs signal/slot), the compiler will try to do that as well when trying to rcc the qrc files, and ultimately failing without throwing an error.
Simply removing ;%(Outputs) in Properties->Custom Build Tool->General->Outputs solved it for me.
I have a dot-net project build with VISUAL STUDIO 2015 4.6.1 framework and I have two independent program folders in the source code which has some build errors. There are no references to these programs from the main program.
When I push the whole source code onto VSTS I get build errors. So now I need a way to exclude those two folders from the manual build for now but may need them later after they are debugged so I don't want to delete them from VSTS too.
Can someone suggest?
Use an MS Build project file. Create an MSBuild project file from scratch
And the at the build solution step in VSTS, select or type the project file path instead of the solution file.
You will have to remove it down the road though. The maintenance tasks tend to be hard and counter-intuitive whenever the code base grows quickly. Visual Studio will not warn you if you have build errors (like obsolete path) in the MS Build project file.
Has anyone done this before ? I am not able to get it to work.
Following are my steps:
Download the windows package from link
I can run qfuzzylite (gui-tool) without any problem. Now I want to use the fuzzylite lib in my Visual Studio + Qt Integration Project.
In the CMake GUI I give fuzzylite source folder as the input folder and select Visual Studio 2010 as the compiler.
I am able to generate the Visual Studio fuzzylite solution in CMake without any errors.
Then, I tried to build the Visual Studio solution, but it fails with some weird errors. However, it does generate the fuzzylite-dbg.lib file (which I need).
Then I use this lib file and the fuzzylite.dll and include the path to the Headers in the VS Project. The project builds without any errors.
Now in the code I am doing
fl::Engine* engine = new fl::Engine("simple-dimmer");
This fails with the following exception:
exception text: bad allocation
exception type: class std::bad_alloc
Thank you for your detailed steps, but the solution seems to be a bit random (or weird as you put it). Unless more information is provided about the error, I strongly discourage the use of such a solution to attempt any fix to fuzzylite.
If you are running into problems, I strongly encourage you to report the problem in the forums at http://www.fuzzylite.com, where I and others will be very happy to help you.
As for the compiling errors, fuzzylite treats warnings as errors. A warning that is being raised in fuzzylite 4.0 when compiled using Visual Studio (not from console via nmake), and potentially in previous versions, is warning C4702, which refers to unreachable code. You can fix this by adding in file fl/fuzzylite.h the following line within the #ifdef FL_WINDOWS (together other #pragmas):
#pragma warning(disable:4702) //Ignore unreachable code
If the library was not built correctly, errors are bound to happen during runtime.
Ok, got it :)
Here are the steps for future reference:
Download the windows package from link
In the CMake GUI I give fuzzylite source folder as the input folder and select Visual Studio 2010 as the compiler. Now, if you want to use the lib in Debug mode tick the FL_DEBUG box (this is where I went wrong)
Now on clicking "generate", it will generate 5 projects:
ALL_BUILD
fl-bin
fl-shared
fl-static
INSTALL
ZERO_CHECK
Now in the Project properties in fl-bin, shared and static go to the Project Properties. In C/C++ go to Preprocessor get rid of the space in FL_DATA="mm.dd.yyyy " to "mm.dd.yyyy" (weird).
The solution should build fine and will generate fuzzylite-dbg.dll and fuzzylite-dbg.lib in the lib folder.
Use these files in your VC Project by adding the fuzzy-dbg.lib as the linker input and place the dll in the solution folder. Give the path "path\to\fuzzylite\fuzzylite." to the Include Directories.
Do the same process for Release mode (don't tick the FL_DEBUG flag)
I'm using Visual Studio 2005 (32-bit) on a Windows XP system. I've got a C++ project that I build from the command line (in a batch file) that uses devenv.exe to launch the build. Here's an example of how it gets launched:
{path_to_devenv.exe} my_solution.sln /rebuild "Debug|Win32" /out my_logfile.txt
Within the code for this project, we use a few pragma statements to disable some extraneous warnings that we don't want to see:
#pragma warning ( disable : 4521 4522 )
// Some code here
#pragma warning ( default : 4521 4522 )
When the project is built in the debug configuration from the IDE, these warnings do not show up in the build output. When the same project is built from the command line, the warnings do show up in our log file (which we specified with the /out command line parameter). When building in release, the warnings do not show up in either case.
Is there something different about driving VS 2005 through devenv.exe that causes the pragma to be ignored in the debug case? Why should these warnings show up in one world and not the other?
Frankly the only reason I can see this happening is when the pragmas aren't seen.
Check
the build configuration (are you building Debug|Win32 from within the IDE too?)
and especially the include paths (are they the same; perhaps see whether the environment contains other settings)
are you doing a full rebuild from within the IDE? I wouldn't rule out that you usually don't see the warnings in the IDE, because you usually do an incremental build and the related sources don't need to be built. Check whether you get the same errors when doing a full rebuild in the IDE
If you are desperate for clues, you can always keep the result of preprocessing using both variants and compare them. The 'keep preprocessed source' option is hidden somewhere under the 'Preprocessor' C++ build settings.
Good luck