For reference, I'm using Visual Studio 2010.
I have a custom build step defined as follows:
if exist "$(TargetDir)"server.dll copy "$(TargetDir)"server.dll "c:\program files (x86)\myapp\server.dll"
This works great on my desktop, which is running 64-bit Windows. However, when I build on my laptop, c:\Program Files (x86)\ doesn't exist because it's running 32-bit Windows. I'd like to put in something that will work between both editions of Windows, since the project files are under version control and it's a real pain to change the paths every time I work on my laptop.
If this were a *nix environment I'd just create a symlink and be done with it. Any ideas?
You can put this in your project file:
<PropertyGroup>
<ProgramFiles32 Condition="Exists('$(PROGRAMFILES) (x86)')">$(PROGRAMFILES) (x86)</ProgramFiles32>
<ProgramFiles32 Condition="$(ProgramFiles32) == ''">$(PROGRAMFILES)</ProgramFiles32>
</PropertyGroup>
And then you can use $(ProgramFiles32) in your post build event.
For more information check this stackoverflow question.
Related
I just want to change the exe file Visual Studio compilation path change
I am doing it like this now. i created a bat file that copied file. I have added visual studio build events. I wonder if there is an easier way.
meanwhile the exe file is being copied to the network drive
I had this problem in a different context (Elixir/Phoenix, Rust), but the root cause was the same: cl.exe could not be found during compilation.
My setup was:
Windows 10, x64
Visual Studio Community 2017 already installed, but only for C# development
For some reason the solution with installing the Visual C++ Build Tools (as #cozzamara suggested) did not work. Stops during installation with some obscure error message. Guess it did not liked my existing Visual Studio installation.
This is how I solved it:
Start up the Visual Studio Installer
Check the Desktop development with C++ (screenshots here)
Execute following command before compiling:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat
From this on the command cl.exe works. Alternatively (and more conveniently for development) start the application 'Developer Command Prompt for VS 2017' or 'x64 Native Tools Command Prompt VS 2017'.
Share
I solved the problem by writing code like this in the Post build field, I just ensured that the exe was copied to the field I wanted
COPY $(TargetPath) "\x.x.x.x\ortak\yakup\TestApp.exe"
pause
$(TargetPath) = It gives the location where the exe exited, along with the exe name
"C:\yakup\project\TestApp.exe" like
My visual Studio 2015 installed without vcvarsall.bat.
This is not about how to find this file and I am also not a python developer.
MSDN states at the bottom of this page:
The vcvarsall.bat file can vary from computer to computer. Do not
replace a missing or damaged vcvarsall.bat file by using a file from
another computer. Rerun Visual Studio Setup to replace the missing
file.
I am running the installation through our local IT department so I only get a fixed version of the setup. It looks like this setup does not install the batch file.
I wonder what other means of generating this "file" (actually it is several files and a folder structure) there are - how does the visual studio setup generate this file and is that generation possible without running the whole setup?
You have some option to "install" vcvarsall.bat.
The obvious to rerun VS setup and add c++ features (maybe your IT dep is kind enough and...)
Install visual c++ build tools
Install windows sdk (select c++ related components)
I'm trying to set up Jenkins in a Windows Server 2012 and Visual Studio 2015 and I cannot build my application using MSBuild, I get some Windows SDK issue.
(ResolveComReferences target) ->
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(2015,5):
error MSB3091: Task failed because "AxImp.exe" was not found, or the
correct Microsoft Windows SDK is not installed. The task is looking
for "AxImp.exe" in the "bin" subdirectory beneath the location
specified in the InstallationFolder value of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86. You may be able to solve
the problem by doing one of the following: 1) Install the Microsoft
Windows SDK. 2) Install Visual Studio 2010. 3) Manually set the
above registry key to the correct location. 4) Pass the correct
location into the "ToolPath" parameter of the task.
I've tried the following:
Create the Registry key pointing to the SDK installed. No sucess.
Uninstall all C++ Compilers, download Windows 7 SDK iso and install, as explained here. No success.
Modify Visual Studio 2015 installation adding and removing components, marking explicitly SDKs to be installed. No success.
When building from Visual Studio it builds fine.
I really don't know what's happening here and why I cannot get it working, seems a bug to me regarding Windows or Visual Studio 2015.
The solution was much easier than it seemed to be, just changing the ToolsVersion of the Project node from 4.0 to 14.0 made the trick:
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
So I had a really similar issue, using Jenkins and Msbuild to build projects, and getting this same error.
My solution steps:
first find out IF Aximp.exe exist on the Jenkins machine. I don't have access to the machine, so I included a stage in my jenkinsfile to run this command:
//temp, try and get location of aximp.exe on build machine
bat 'dir "C:\\Program Files (x86)\\Microsoft SDKs\\Windows" /b /s aximp.exe'
I then reviewed the output to see where it lives.
then, I added a parameter to my msbuild command in my jenkinsfile like this:
bat 'msbuild mysolution.sln /p:VisualStudioVersion=14.0 "/p:TargetFrameworkSDKToolsDirectory=C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v10.0A\\bin\\NETFX 4.6.2 Tools" ' //your folder where aximp.exe lives
And the build now runs!
I have this command in a post build event:
if $(ConfigurationName) == Release "$(SolutionDir)Tools\NuGet.exe" pack "$(ProjectDir)MyProject.Contracts.nuspec"
This works just fine when I compile in Visual Studio. But when my build runs this it fails. That is because someone somewhere thought it was a good idea to have builds on TFS not run the same as a build on a dev machine.
In this case it is the fact that all output files are grouped into a common "Binaries" folder.
So, my question is this:
Is there a property I can use (instead of ProjectDir) that will allow me to reference the output location of the build?
Meaning that it will point to the binaries folder when running a TFS build and point to my normal output when doing a normal Visual Studio based build.
I tried $(OutDir) but it equated to "bin\Release\"
UPDATE: I tried to use $(OutDir) but Visual Studio fails with the partial path it provides. Is there something that could be used with $(OutDir) to give a full path for both Visual Studio and TFS builds?
In case it matters:
TFS version is TFS 2010 (Latest releases installed)
Build Machine and Dev Machine are both running Windows 7 and VS 2010 Ulitmate
$(OutDir) should resolve to your bin\debug or bin\release etc for local builds, on the build server this will be resolved to the Binaries folder.
So yes, $(OutDir) should be the right one to use.
I am taking over a bit of a legacy project, and having issues getting it to install in Windows 7.
The project is coded in VB, and our IDE for it is Visual Studio 2005 with VSS (fun I know). It was originally created for XP. The original dev is around to coordinate with, but is off the maintaince team for this project, and admits that the code is quite poorly formatted and commented it was his first large project.
The project runs fine when I generate a debug or release build in Visual Studio 2005, and I can run it on the Windows 7 machine that built it just fine. However, the MSI that I generate to install with fails when run on Windows 7.
It looks to be an issue where the DLLs that are packaged with the project are not correct for Windows 7, but they were generated via an MC file. I have the source MC files, so attempted to use MS's mc.exe tool and its counterparts to create the dll, but am not seeing any output.
The only walkthroughs I have seen on using MC files are not terribly helpful: mc_tutorial
MS mc.exe page
Could someone else walk me through what steps are nessary, or point me toward some more helpful resources?
An actual high quality man page for mc.exe would be quite nice, instead of the rather limited MS documenation, but maybe I am spoiled these days.
look for mc.exe in you machine (mc.exe is part of windows sdk usually located at C:\Program Files (x86)\Windows Kits\10\bin\10.0..\x64\mc.exe).
in windows command prompt run : "C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\mc.exe" -U sample.mc
after above command run: "C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\rc.exe" -r sample.rc
above command will generate header in your sample.mc file location.
run this command to generate dlls: link -dll -noentry -out:sample.dll sample.res