Step 1 - I have installed visual studio build tools by downloading
vs_BuildTools.exe from this site (you will require to login to microsoft account to browse this URL)
Step 2 - I created offline installer by following various articles particularly this one
And created zip file offlineBuildTools17.zip
Step 3 - Copied offlineBuildTools17.zip file to Build server which doesn't have internet connection.
Build server is Windows server 2012 R2.
Step 4 - Extracted Zip file on server and installed Build tools. Installation goes smoothly.
I could see installation files in
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft
Step 5 - I have simple DLL and Console application (.exe) project in my solution. These are simply 'hello world' application NOT USING DOT NET CORE. I am using .net frameowrk 4
Problem: I am unable to create release mode dlls and exe
Same thing is working on my laptop where I have installed visual studio 2017 community edition.
On laptop where visual studio 2017 installed
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild" <optional project.csproj> /p:Configuration=Release
This creates dlls and exe in bin\Release folder of project
But the same doesn't work on Build server.
Always creates dlls and exe in bin\debug folder.
My final goal is to create 'publish' folder
This is weird but it is solving my problem.
if i ran following command - msbuild is always generating Debug binaries. which was my original problem. it doesn't generate release mode binaries at all
"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\"msbuild /p:Configuration=Release /t:publish /p:OutDir="./Publish"
But if i write following command , (note how msbuild is placed in double quote along with mbuild full path) it is working fine. it generates release mode binaries and also publish folders.
"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\msbuild" /p:Configuration=Release /t:publish /p:OutDir="./Publish"
thanks
Related
How can the entry
<MsTestExePath>$(MSBuildProgramFiles32)Microsoft Visual Studio 14.0\Common7\IDE\mstest.exe</MsTestExePath>
in a .proj file be generalised, such that the build works for different licenses of Visual Studio 2019 as well, where mstest.exe is located at
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\Common7\IDE\MSTest.exe
in the case of an enterprise license?
The most generic solution may be to replace the variable parts of the path with msbuild macros, but which ones would that be?
According to this documentation,
The macro
$(VSInstallDir)
returns the path to the installation folder of the Visual Studio version currently used.
The following entry should therefore work for all versions of visual studio, for which mstest.exe is located in the subfolder \Common7\IDE\ under the installation directory:
<MsTestExePath>$(VSInstallDir)Common7\IDE\mstest.exe</MsTestExePath>
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.target
error MSB3147: Could not find required file 'setup.bin' in ... folder
I have seen there are similar messages during the time frame of last upgrade of VS for 2012.
I did not find the registry keys on the build server as mentioned in other posts i.e. Could not find required file 'setup.bin'
I appreciate your help.
Teamcity: error MSB3147: Could not find required file 'setup.bin'
According to this blog entry the bootstrapper files are installed during the .NET Framework SDK/Visual Studio IDE install. It also shows the registry entries that are searched to look for the bootstrapper directory.
If one computer that does not have .Net Framework SDK/Visual Studio IDE installed(such as, build server), none of the registry key would be set.
I did not find the registry keys on the build server as mentioned.
You can install .Net Framework SDK/Visual Studio IDE on the build server to get this registry key. If you don not want to install them, you could manually set it up by following steps:
Copy the whole C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK folder from the local machine with Visual Studio IDE installed to the server.
creating the 14.0 registry key and adding the value:
For 86bits:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\14.0]
"Path"="C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper"
For 64 bits:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\14.0]
"Path"="C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper"
Note: Visual Studio must be restarted.
I don't have SDK installed on the server. I have updated the .csproj with
<PropertyGroup>
...
<BootstrapperEnabled>false</BootstrapperEnabled>
</PropertyGroup>
That fixed the build.
While I am building own Visual Studio Extension in TeamCity (same applies to any CI server build that supports building VS solutions), my build stucks on the step DeployVsixExtensionFiles. As far as I understand, the target is defined in VS Extensibility files and is being imported into any .csproj by default. I also realize that this is an "aka test" step that tries to embed an extension into a virtual copy of VS via running a command:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe /RootSuffix Exp /ResetSettings General.vssettings /Embedding /Command File.Exit
I have two questions:
1. Should I disable this step for Release build of Extension?
2. If yes, how can this be done.
The VS SDK installs the extension as a part of a build so you can F5 and run it. If you're CI system doesn't care about that, update your CI configuration to pass /p:DeployExtension=false to MSBuild.
Having tried to follow all advices, remedies and workarounds including removing and reinstalling the Multi-Device Hybrid Apps for Visual Studio CPT1 I still can't seem to do a successful build of the included "Blank App (Apache Cordova)" project.
Build ends consistently in one single error:
The command ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7
\IDE\Extensions\k04kuuo3.ie0\packages\vs-mda\install" "C:\Program Files (x86)
\nodejs\" "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7
\IDE\Extensions\k04kuuo3.ie0\packages\vs-mda"" exited with code 8.
File %USERPROFILE%\AppData\Roaming\npm\node_modules\vs-mda-targets\Microsoft.MDA.targets
Line 108
Column 5
Project BlankCordovaApp1
Environment settings:
ADT_HOME %USERPROFILE%\AppData\Local\Android\android-sdk
ANT_HOME C:\apache-ant-1.9.3
GIT_HOME C:\Program Files (x86)\Git\cmd
JAVA_HOME C:\Program Files (x86)\Java\jdk1.7.0_55
PATH %JAVA_HOME%\bin;%ANT_HOME%\bin;%ADT_HOME%\platform-tools;%ADT_HOME%\tools;
C:\Program Files (x86)\nodejs\;C:\Program Files (x86)\Windows Kits\8.1\Windows
Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\
(contains no reference to "Platform")
Your kind help is very much appreciated, Thanks Ian
I just ran into this on one of my PCs and here's how I got it fixed:
Quit Visual Studio
Open the Android SDK manager by typing the Windows key and then "SDK manager", hit enter
Install Android Build Tools Rev 19 by checking the box next to it and clicking Install packages
Accept the license
Open Visual Studio and your project, then run it again
Jordan (Microsoft, Multi-Device Hybrid Apps tools team)
Finally the light bulb went on for me: The problem was the install batch files not being able to locate xcopy.exe and therefore the simple remedy was to just extend the path variable with
%SystemRoot%\system32;
The build now runs without further errors.
Thanks Jordan and Ian.
I ended up doing both.
I ran the Android SDK manager to install the Android Build Tools Rev 19 as well as some other updates.
I also added "%SystemRoot%\system32;" to the PATH environment variable.
Everything running as it should.
I am trying to run (and debug) my application on a remote computer where Visual Studio 2005 is not installed.
My current problem is that I am facing the (in)famous error : "The application failed to start because the application configuration is incorrect".
Here is what I did :
1) Install all the required vcredist on the target computer :
(I do need all theses versions since some libraries were compiled some months ago, with a previous runtime...).
Microsoft Visual C++ 2005 Redistributable Package (x86)
Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)
Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update
Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update
After installing those redist, the release version works fine.
2) Install the debug dll following the instructions given on the following MSDN pages: Preparing a Test Machine To Run a Debug Executable and at How to: Deploy using XCopy
As mentioned in "Preparing a Test Machine To Run a Debug Executable":
I did run "msiexec /i microsoft_vc80_debugcrt_x86.msm" --> This did not solve the problem.
After that, I added "msiexec /i policy_8_0_Microsoft_VC80_DebugMFC_x86.msm" --> No luck either.
As a last resort, I did "msiexec /i" for all the msm that are in C:\Program Files\Common Files\Merge Modules\*VC80*.msm --> No luck either
As mentionned is "Deploy using XCopy":
I also copied (in subfolders) all the subfolders of
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\
and
C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\
to my app dir on the target machine.
The problem is still present.
Does anyone know what I might be missing ?
Let me answer my own question : the easiest way is to add a "Setup and deployment project" to the solution.
Right click solution / Add new project : Other Project types / Setup and deployment
Right click the new deployment project and select "Add/Project Output" then select your target project
--> this will create a msi that will install all required debug dll !
(Once installed by the msi, the debug dlls are deployed once and for all : you will not need to reinstall them using an msi each time you want to test a new build).
You can use the Dependency Walker tool to find what DLL(s) you missed.