In recent earlier versions of Visual Studio (i.e.: earlier than VS2017), Microsoft released a separate code metrics powertool that could be run through the command line and generate an XML containing certain code metrics (such as lines of code, complexity, and maintainability) for your codebase. Details about the tool here.
As far as I can tell, they have not released a version of this tool that works based on a VS2017 install. While the VS2017 IDE does contain a tool to generate and even export these metrics (under Analyze->Calculate Code Metrics), I can't figure out a way to use it via the command line so that the process can be automated.
Is there a way to do this without 3rd party software?
For VS2017, there is currently no command line support to 'Calculate Code Metrics' - as you say it is only present in the IDE.
In previous versions of visual studio, this functionality was provided by via the CodeMetrics Power Tool.
You can see an issue raised here for lack of Power Tool support in VS2017:
https://developercommunity.visualstudio.com/content/problem/142328/code-metrics-powertool-missing-for-vs2017.html
where the Visual Studio team states that they currently do not have any plans to produce the power tool.
Therefore, at this point in time, you will require 3rd party software.
Related
I would like to be able to compile C and C++ code under the Windows environment without using an IDE, just by using the Windows Command prompt (cmd.exe).
I come from Linux, where you are be able to install the gcc package with just a command in the terminal:
$ sudo apt install gcc
I wonder if there is a C/C++ compiler collection in a package inside the Windows install folders, just like the ones in Linux, I just need to install.
What also gives me a reason to ask this question is:
Since the kernel of Windows and the Windows API are written in C, and many of the high-level applications of the actual Windows 10 release are written in C++, it would be reasonable to also directly provide a suitable compiler suite. This is my thought modell, does not need to match reality.
Thanks for your help.
Since the kernel of Windows and the Windows API are written in C
Microsoft doesn't ship a compiler, or the required Windows SDK headers/libs (also includes a bunch of other useful development tools) for Windows in the installation.
Microsoft Visual C++ (part of Visual Studio) would be the equivalent "built in" choice although I am not sure if Microsoft ever specify exactly which version they use for a given Windows build and it is common to have lots of software built with different compilers/versions (including the various non-Microsoft ones).
As well as the full Visual Studio package with the IDE and other tools. Microsoft provide some components separately, such as the Build Tools for Visual Studio 2019.
I am sure this is for many reasons like most users not being interested in compiling their own software, and Microsoft still sells Visual Studio separately to larger organisations (historically to most serious users, but "Community" edition is now pretty nonrestrictive for individuals and small business).
Strangely enough it doesn't come with a C compiler, we need to install one, Mingw-w64 is allways my choice, you will need to add the path in environment variables (step 12), if you want to use it anywhere. You can then use the gcc command where it's more convenient like in Linux, don't forget to open a new cmd after the changes for them to take effect.
Unfortunately, Windows doesn't have the command line tools for installing/removing stuff and the great repository infrastructure we know and love from Linux.
You will need two things:
The command-line build tools. These can be found on the Visual Studio Downloads page under Tools for Visual Studio -> Build Tools for Visual Studio. This will include the compiler (cl.exe) and linker (link.exe) for the MSVC build toolchain.
The Windows SDK. The latest version of the SDK can currently be found here. This page has a tendency to move around, but googling for Windows SDK usually gives you the right page immediately. The SDK contains all the headers and libraries required to build Windows applications and make use of the Windows native API. The Windows SDK contains a lot of stuff which you may or may not need. You will almost certainly want to install the Windows SDK for Desktop C++ x86 Apps and Windows SDK for Desktop C++ amd64 Apps components. Most of the other stuff should be optional, but some of it is nonetheless highly useful.
You may want to download additional packages such as the Windows Debugger (which is an entirely different application than the Visual Studio debugger) or the Driver SDK, depending on what kind of things you want to develop.
Note that even if you don't intend to use the IDE in the end, installing the full Community Edition of Visual Studio is a far more convenient way to get a working build environment, so unless you have a really good reason not to, just go with the full package and choose to never open the IDE.
The built in compilers available on Windows 10 are for VisualBasic, C#, JScript.
To improve speed & performance of apps, "ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly".
For low level programmers, ilasm.exe (IL Assembler) ships with Windows, which also facilitates "tool and compiler" development; so you could even create your own language or build a better compiler for a current one, or "debug your code at low level and understand how .NET deals with your high level code", or "write your own compiler for a new .NET language."
For web programmers, AspNetCompiler precompiles server-side ASP.NET web-applications, therefore helps application performance because end users do not encounter a delay on the first request to the application.
All Compilers & assemblers come as builtin with Windows without IDE and can be run from "the Windows Command prompt (cmd.exe)", so no extra downloads necessary; located in folder: C:\Windows\Microsoft.NET\Framework\vx.x.xxxxx\ .
Note: C# is based on JScript.
Compilers:
vbc.exe
csc.exe
jsc.exe
ilasm.exe
ngen.exe
aspnet_compiler.exe
Addendum:
If you still are looking for a C compiler to handle some C source codes you already have spent your life on, then (without downloading) you can make/write a C compiler, in a high level language, then optimize it with a low level language.
This guide will "introduce you to the high-level architecture, theory, and .NET Framework APIs that are required to build your own .NET compiler" in C#.
You can to use gcc for windows. For e.g. mingw, tdm-gcc, mingw-68, Cygwin etc. Each of them allows you to work on c/c++. But if you are not sure about the installation process, and don't want to do all the work by yourself, the easiest solution is to download something like dev-c++ or code-blocks.
cygwin: https://cygwin.com/
mingw-64: http://mingw-w64.org/doku.php
Downloadable file can be found here (for mingw, dev-c++): https://sourceforge.net/
You can also install Microsoft compiler. I usually do it by installing the whole visual studio.
I'd rather not install the entire VS 2008 installation given that I'm not going to be using anything other than the compiler. Will VS 2010's multitargeting work correctly using only the Platform SDK instead of the full VS2008 install?
The custom setup options are not nearly fine-grained enough to allow you to leave the big chunks like the IDE out. It isn't just the SDK that's used, at least the VC subdirectory needs to be there. And bits of Common7, also the folder that contains the IDE. Rename the folders, delete them later if it works out.
You can directly call the .net 3.5 MSBuild from command line by digging it out of the frameworks folder within windows. I am not certain if you could repoint Visual Studio at a different copy though. More importantly, unless you have found a bug, the copy of MSBuild included in the .Net 4 framework should properly build a project targeting the 3.5 framework. So you might be jumping through some unnecessary hoops in the first place.
I'm using Visual Studio 2008 for C++. When compiling, Visual Studio compiles against the header files of the VC 9.0 libraries. However, there are different versions of this library available:
v9.0.21022.8 (= RTM)
v9.0.30729.17 (= SP1)
v9.0.30729.4148 (= SP1 with security update)
I'd like to know whether it is possible to tell Visual Studio which version it should compile against.
The reason I think this is important is because the application's installer needs to make sure that the correct version of the Microsoft Visual C++ 2008 Redistributable Package is installed. To me it feels like I don't have any control over this dependency, as apparently some Windows Update (not a Visual Studio update) can change this dependency. I'd like to keep using the same version to avoid the overhead of making the installer upgrading the Redistributable Package.
Note that this situation is different from my earlier question, as that one was about link time. Neither am I looking for a way to control the version that is put in the embedded manifest file, as that is explained here.
The manifest that's included with your binaries is automatically generated by the VS build system. Important headers that determine the version dependency that's emitted into the manifest are vc\include\crtassem.h and crtdefs.h. The former declares the CRT version. Note that it already has support for the RTM version vs the "latest" version with the _BIND_TO_CURRENT_CRT_VERSION macro. The latter contains #pragma comment directives to embed the /manifestdependency linker option into the .obj file, which in turn makes the linker auto-generate the manifest.
You don't have to do it this way, you can simply turn off the linker options that generate the manifest and write your own. That gives you complete control over the CRT version that your app binds to. Whether you are ahead with this is a bit questionable. You would probably still be shipping the old version of the CRT that got updated in July of last year, it contained a critical security bug. Customers tend to be a bit unhappy about getting software installed on their machine that has well documented and solved security flaws.
The next thing you'd have to do is take control of the deployment of the DLLs. You'll have to deploy the DLLs into the WinSxS side-by-side cache yourself.
That will work, if you figure out how, but it isn't likely to survive for very long. Windows Update, if enabled, may discover that the machine is using an unpatched version of the DLLs and will update it. And deploy a publisher policy to redirect load requests. It is likely that your machine has such a policy file in place if you see your manifested version request resulting in the load of another version. The somewhat unescapable conclusion is that this is MSFT's DLL and they'll do with it what they think is necessary. Look at applocal deployment to avoid this.
It's this just a question of which directory your configuration is set to build against. As long as you have all the versions of headers on your machine and the libraries they link against I don't see why this can't be a new configuration for each version.
If the issue is things like SP1, there's not much you can do. Microsoft considers the runtime, in effect, a component of the operating system. It therefore gets updates and patches the same as any OS component.
There shouldn't be a problem with this, normally - the patches are bugfixes and security updates after all. In principle, each change should make your apps more stable. Not quite always true, but in any case there isn't much you can do about it.
There are options to change the runtime, but they are related to thread-safety and similar issues. There's a few relevant places in the project properties. In particular, in the C/C++/Code Generation tab you can select which run-time library to use.
If you are seriously worried, you can choose a statically linked non-DLL runtime. Users can still update their runtime DLL, but it won't improve the stability of your app when they do so.
You can do this using manifest resource files, which are written in XML.
We had to do this at a previous place of employment, unfortunately (or perhaps, more fortunately), I was not exposed to the in depth details of how it was done. This article looks about the closest to what we did that I could find on the subject.
Update0
Here is MSDN documentation regarding manifest file generation, and their use in isolating applications and building side by side assemblies.
I am looking for a program that can take the program I made in Visual C++ 2008 and distribute it in a mature installer for Windows. I want an application that is FREE (or trial).
The setup and deployment folder is not there when a select File-->Add-->New Project
You can try NSIS (Nullsoft Scriptable Install System), which is free, but can be confusing because it's lots of scripts. That said, it can do anything you might want to do.
Install Creator from ClickTeam is very simple to use and is my preferred application but it does cost money.
WiX has a fairly steep learning curve, but it gives you full access to all features of Windows Installer, with no limitations. It's originally an Microsoft project, and is what Microsoft uses internally for many of its products. It's free and open source under the Common Public License (which permits its use in closed-source products without requiring you to license your own code under it).
For a setup .exe I like Inno Setup, which will let you do desktop icons, amongst other things. Basically you create an Inno Setup installer file which you can pass into the setup compiler which means you can also build it from the command-line. They provide both a GUI and a command-line compiler. The bundled documentation is also very complete.
For MSI you can try the Windows Installer XML (WiX) toolset., which is similar to Inno Setup in that you can compile from the command-line, but a certain amount of Windows Installer / MSI knowledge is expected.
Use setup project in Visual Studio
Check the following programs:
Inno Setup
NSIS
Don't forget to include Microsoft Visual C++ Redistributable Package
Take a look at InstallJammer. Free, open source and easy enough to make a simple installer in minutes while also supporting complex, scripted installers if you find you need them.
What are the pluses and minuses to using the vcredist.exe versus the msm files to install the Visual C++ 8.0 runtime libraries?
Merge Modules can not be updated (unless they solved that in Windows Installer) once they are installed, so my advice would be to stick with vcredist.exe.
Another issue with the merge modules I recently bumped into is that they set the MSI installer property ALLUSERS to 1 which means per-machine. That forces your whole install to be per-machine, which is a problem if you want it to be per-user. Whether there's a way to have a per-user installer that includes a CRT merge module I don't know, but I haven't found it yet.
One downside to the merge modules is that you can't deploy multiple versions of the VC80 or VC90 merge module in the same msi because the file identifiers overlap. You can deploy one of each though. So for example, if you wanted to deploy the RTM version of VC80 and the SP1 version, you will get errors if they are in the same msi (I use WiX).
Another issue, build behavior is different between VS 2005/2008 as it pertains to applying a service pack or update.
2005
If you install service pack 1 on your build machine, your program will automatically link against the updated files. The service pack will also update the merge modules, so provided you're pointing your installer to use the updated files, you're fine. However, this can be an issue if you're using third party compiled static libs that may require an older version of the runtime specifically.
2008
The behavior here is the exact opposite. If you install SP1, the merge modules are updated to the SP1 level, but your program will compile against the RTM versions unless you set a per-project preprocessor macro: _BIND_TO_VCLIBS_CURRENT_VERSION=1. This can be set either in stdafx.h or in the "Preprossor definitions" for your project, or if you're using an old nmake project, you will have to pass it wherever your command line options are, such as CFLAGS.
This means that if you're using the msm provided by visual studio, and you apply SP1, your project deployment is broken until you define the macro.
Another caveat to the macro: if you're using a 2005 project that links against a 2008 static lib, setting the macro will break the 2005 project, due to the symbol not existing in the 2005 version of the compiler. In this case I usually split the project I'm linking against into a 2005 and 2008 version of the solution.
To point out the obvious, Merge Modules are not really a good solution if you aren't going to use an MSI installer. Vcredist is absurdly simple to use regardless of the install process you are using.
MSM will give you a better streamline experience then vcredist, it will integrate with the progress bar and will rollback on error (or cancel).
From the developer side you will benefit by seeing the msm log in the main setup log file and it will execute its actions side by side with the setup action (with vcredist you will need to sequence it yourself).
Because of all of the above reasons I usually choose to use the msm (and its more or less one Wix liner to use it).
Have you considered statically linking instead? Then you don't have a redistribution problem.