Where can I find the build script -all the list of tools used to build and link the assemlies like al.exe etc.-that BUILDS, REBUILDS the visual-Studio solutions?
MSBuild (the build engine for Visual Studio) uses a model where the tool(s) used for an action are dictated by the project file being built. Thus your list of tools will vary based on the types of projects you are building. The easiest way to find out the list of tools being used for a build of any given solution would be to turn on a more detailed logging level (detailed or diag) for MSBuild via Tools->Options->Projects & Solutions->Build & Run in Visual Studio and then parse/investigate the build output for an indication of the tools currently invoked by the Build Targets.
As Nick Nieslanik has said in his answer, the actual toolset will vary based on the project type (and target programming language), maybe even the selected .NET framework version.
To have single view on all definitions, properties, targets, etc. used by MSBuild, you could generate and review a fully preprocessed project file (only available with MSBuild 4.0 or newer).
From msbuild.exe /? output:
/preprocess[:file]
Creates a single, aggregated project file by
inlining all the files that would be imported during a
build, with their boundaries marked. This can be
useful for figuring out what files are being imported
and from where, and what they will contribute to
the build. By default the output is written to
the console window. If the path to an output file
is provided that will be used instead.
(Short form: /pp)
Example:
/pp:out.txt
Example:
msbuild.exe myproj.csproj /pp:out.xml
In this case out.xml is basically a self-contained file that has all the Import-ed project files inline so you can easily search and browse them.
In each project (in this case a c# csproj) file is a link to the msbuild used by msbuild/visual studio to build.
e.g. <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
This target links to the internal files used.
Related
When I attempt to publish my package using NuGet Package Explorer, I see the following warning:
Deterministic (dll/exe): Non deterministic
Ensure that the following property is enabled for CI builds
and you're using at least the 2.1.300 SDK:
<ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
However, when I add that property to the PropertyGroup (as described here), VS 2019 freaks out so badly I literally need to ctrl+alt+delete to close it.
According to this page the property name is <Deterministic>, but that doesn't seem to do anything at all.
So how do I get deterministic builds to work?
Visual Studio 2019, v16.7.1
.Net SDK 3.1.401 (LTS)
An easier answer is to not mess with .csproj files (urgh!) and do this via the command line, in your CI script.
add the /p:ContinuousIntegrationBuild=true argument to the dotnet pack command.
dotnet pack
-c $env:CONFIGURATION
/p:ContinuousIntegrationBuild=true
-p:PackageVersion=$env:APPVEYOR_BUILD_VERSION
(make this all one line. I've multi-lined it, for readability)
NOTE: the --no-build argument is NOT here. We need to build this again. Or you add that param to the build step, before this.
This is taken from an example CI file I use. So when I'm in release mode, I pack the library into a nuget and publish it.
Keeps things clean and out of your .csproj file (which is very hard to grok and maintain).
I basically just found the answer in this blogpost:
While deterministic builds are enabled by default in .NET SDK projects, there is an extra property, ContinuousIntegrationBuild, to set on the build server to normalize stored file paths. These should not be enabled during local dev or the debugger won’t be able to find the local source files.
<PropertyGroup Condition="'$(TF_BUILD)' == 'true'">
<ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
</PropertyGroup>
How does Visual Studio (2015) work with external tools like NPM and Typescript compiler (tsc.exe) etc.? I guess, at the time of building the solution or project, something must be telling MSBuild to run these extra tools. I want to understand this under the hood operation.
It all depends...
Visual studio has multiple services and features that interlink here:
Language Services - Visual Studio can be extended with so called language services, these provide intellisense, syntax analysis, highlighting etc. For Javascript and Typescript Microsoft provides a Language service that provides such information.
MsBuild - Underneath most of Visual Studio projects lives an MsBuild project. If you search your Program files directory you'll find an MsBuild folder and underneath that there are a number of target files. This includes one for Typescript which will transform your .ts files during build. These targets files either directly use the exec MsBuild task to run tools or provide a custom MsBuild task in the form of a .NET Assembly that implements specific interfaces. These tasks can either implement the required action themselves or shell out to a tool to have it perform the action.
Roslyn - For C# and VB.NET the parsing of the projects and the background compilation of the sources is handled by a new compiler called Roslyn. This actually runs in the background while you type and has a very powerful in-memory model of all your code in your project. Roslyn supports add-ins as well in the form of analyzers and refactor action that either provide the user with feedback on common errors or provide ways to automatically rewrite/change the code.
Task Runner - The Visual Studio Task Runner is a plugin for Visual Studio that first shipped as an extension and is now part of Visual Studio. It reacts to events in the IDE (build, test, etc) and can associate actions in your package.json or grunt or bower etc scripts. The plugin will make sure your script commands are executed at the right point in time during the builds.
Test Runners - The Visual Studio Test Window has support for extensions as well, so the Mocha and the Chutzpah extension in your project will be picked up and during the test execution these plugins will be asked to first list and later execute the tests. These runners act as a kind of proxy, feeding back the list of tests and their status after execution.
Custom extensions - There are many other ways in which some vendors extend Visual Studio by providing a generic extension. These extensions may contain any of the above elements or may just listen to the events generated by Visual Studio while you do your work and react on them.
You can see the references to the typescript items if you open the .csproj
with a text editor (or from visual studio : unload the project, right-click on the project and choose edit myproject.csproj )
You'll see the typescript resources :
<ItemGroup>
<TypeScriptCompile Include="src\config.ts" />
the target for the build :
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
The external tools, are configured in Tools/Options :
To automate C++ code quality analysis in our company, I've been asked to integrate Cppcheck tool with our SonarQube server (through the C++ Community plugin).
For the C++ part of our main product, in Visual Studio, we have a dozen of solutions, with almost a hundred of projects within each solution.
We use standard inherited property page macros like $(SolutionDir) and $(ProjectDir), and define our own custom (user-defined) macros as well (via Property Manager).
I'm currently writing Windows command line batch scripts to perform static code analysis separately on each solution. The idea is to run Cppcheck with an option like --project="solution_name.sln" and then run SonarQube Scanner to parse the generated XML output.
But there's a problem. It seems that Cppcheck doesn't recognize these $(SolutionDir) macros during include path resolution. (When run with --check-config option, it complains about missing include files.)
Unfortunately it turns out I even cannot supply additional include paths for a solution because the -I and --includes-file options are ignored when --project is specified.
How is Cppcheck supposed to be used with Visual Studio projects in an automated environment? I'm talking about command line interface (to be used on server side), not about interactive plugins (as used locally on developers' machines).
One possible way would be to create a Python script to preprocess the hundreds of project (*.vcxproj) files, replacing all these macros with real paths (each time after checking out from SVN and before executing Cppcheck). Or is there a proper way to make Cppcheck recognize Visual Studio macros?
Yes the --project is supposed to work. It's just that --project is a very new feature.
I would like to have a simple solution so I can reproduce easily.. Could you create some simple solution with such configuration? no real code is needed. I think a cpp file with just a #include and then an empty header might be enough. Configure it so that Visual Studio finds the header but Cppcheck doesn't.
Please attach it to the ticket orbitcowboy created.
It seems that since VS2010 and MSBuild 4.0, VisualStudio and MSBuild are able to resolve and build project references that are not located within the solution.
Let us create an example to be more concrete. Create a solution called Solution1 with a C# project named A and another project called B. In project B, add a reference to project A. Now create a new solution called Solution2 and click "Add Existing project" and select Project B. There is a warning that can be seen in Solution Explorer and the Warning List.
The trick is that even with "warning as error" we are able to build Solution2.sln. Actually, project A is found
and built by Visual Studio or MSBuild. Let us verify this by opening a VS2010/VS2012 command line and execute the following commands:
msbuild <dirPathToSolution1> Solution1.sln /t:clean **cleaning up solution1 with project A"
msbuild <dirPathToSolution1> Solution2.sln /t:build
ProjectA is effectively built and worse: the warning mentioned above is not even raised there. With previous versions of Visual Studio such situation could not happen (I have tested it with msbuild 3.5 and VS2008).
However, in our situation we would like to prevent such things. Indeed, we have a large source repository with several solutions and many committers. We are reorganizing our dependencies aiming finally to the extraction of smaller repositories. Meanwhile, we do not want developers to add hidden project dependencies without seeing it. We would like to allow only project references "inside" a solution, leaving other dependencies to assembly references.
So the question is "Is there a way, to prevent such solution such as Solution2 to build ?". Ideally, it should not compile with both VS2012 and MSBuild. However a solution involving only the MSBuild command line would do thanks to our Continous Integration.
edit I checked Microsoft.Common.Targets and there does not seem any way to achieve what you want. Either project references are built, or they are not (this is for instance influenced by the BuildProjectReferences flag of my original answer). There is no way to build them selectively depending on which solution they are in unless I'm missing something - which is mainly because project references are set on the project level, not on the solution level: in your project file there is an MsBuild ItemGroup named ProjectReferences and that is used. (Actually this makes some sense: if you ask MsBuild to build projectB.csproj, and B says it references A, then no solution comes into play and you could expect it to build A, after all you are referencing it).
Now as I understand it, you want to prohibit referencing across directories whose structure happens to be represented by solutions. If that is the case, and you really need this, you could probably get away with a tool that parses the MsBuild log and looks for lines like
Project "somedir\projectB.csproj" (2) is building "someOtherDir\projectA.csproj" (3) ...
then extract the directory info from it and make the tool raise an error when they do not match. Then incorporate the tool in your CI server and feed it with the msbuild log files.
original answer
Try with /p:BuildProjectReferences=false on the command line. As the name suggests it will disable building of referenced projects. When building solution1, this should not be a problem since projectA will be built anyway as it is in the solution. However when building solution2, it won't build projectA and you'll get a build error.
Does anyone know if VB6 IDE has the ability to run pre-build events prior to making and compiling the code (this is for creating a .vb file from a template file for subversion revision numbers to be compiled into the code using SubWCRev.exe).
Thanks
There is no method to do this from the IDE. My company built a utility (in VB6) to do our automated build process including steps like you mention (updating version numbers, etc).
The essential trick is that you can run VB6.exe from the command line to compile projects. To see a list of all the option just goto the VB6 directory and type
VB6 /?
A list of all the command line options will appear.
This is what we use for our build utility.
VB6 /Make <project name> /out <errorlog filename>
We copy our project to a temporary project files and alter it using check boxes and parameters files. For example we can choose to compile everything as binary compatible or project compatible. The VB6 project files are easy to manipulate as they are just text. There are any number of things you can do if you write your own build utility.
We use Visual Build Pro to do this. It has built-in support for updating the version numbers of VB6 projects. Our project group includes ~7 ActiveX projects which is really painful to build within VB in the correct order, so we just always use Visual Build Pro because it automatically handles building the projects in the right order based on their dependencies.
There is some support in NAnt (or possibly NAnt.Contrib) for building vb6 projects. NAnt can then handle all of the pre/post build events. Just be prepared for some tweaking.