I currently have VS2013 and VS2015 installed on my machine.
By default FAKE F# Make seems to be building with VS2015.
I tried passing into my MSBuild task the VisualStudioVersion 12.0 but that didn't seem to have any effect.
I saw some articles say to change the MSBuildPath in the Fake.exe.config but I don't see the MSBuildPath in that exe.
How do I make sure it uses the MSBuild provided with Visual Studio 2012 (12.0)?
This code works for me:
let toolsVersion = "12.0"
let setParams defaults =
{ defaults with
ToolsVersion = Some(toolsVersion)
}
build setParams solutionPath
|> DoNothing
#Andrew code didn't change MSBuild version for me. I figure out another way do achieve this.
EnvironmentHelper.setBuildParam "VisualStudioVersion" "14.0"
You could also use "12.0" for vs2013 or "15.0" for vs2017.
Here is link to Fake source that use this variable during the build.
Related
Let us say that I want to find all instances of where AddFileForDownload in used in my script to Visual & Installer in Visual Studio.
When I do it to usual way:
And it produces results as I expect:
But when I try to use the bespoke feature in Visual & Installer:
I end up with this:
If I drag the pane out it then looks like this:
I am using:
Visual Studio 2019 (16.6.2)
Visual & Installer (1.0.4.8)
This is an issue in VS 2019 which is caused by blocking any extension from synchronously autoloading since 16.1, see: https://devblogs.microsoft.com/visualstudio/updates-to-synchronous-autoload-of-extensions-in-visual-studio-2019/
In V&I this applies to Suggestions (Light Bulb actions - Add File(s) / Add Folder into script) and the References window. Both must be reworked/fixed for VS 2019.
The Suggestions are already done and we are currently working on the References window.
Both will be ready in next V&I release.
Update 27-11-2020: The transparent (blank) controls in References windows are caused by changes in .net DPI awareness: https://blog.jetbrains.com/dotnet/2019/06/11/blank-tool-windows-resharper-visual-studio-2019-net-framework-4-8-per-monitor-dpi-awareness/
Temporary solution is to uncheck Optimize rendering for screens with different pixel densities via Tools | Options, then Environment | General.
Update 2020-11-30: Today we have released an updated version of this tool where we have fixed this issue (it is necessary to reinstall the extension in Visual Studio 2019).
See the details and get latest version from official website: http://visual-installer.com/changelog.html#10410
I have existing project in Visual Fox Pro 9 SP2. I added this project to source control over VFP IDE with MSSCCI provider integrated, then I added files to source control. Everything was ok, but then I update project list and error
"cannot update project from project metafile"
occurs.
Same error is shown when I try join source controlled project to other workspace.
There is problem with PJM file (error description on msdn), but I don't know how solve it. I did not change file manually, there is no conflict and there is no format problem because it was generated automatically by tool.
Can somebody explain me why I have this problem and how solve it?
Thank you
Finally I found file path with problem - path contains comma :)
sestavy\katalog\seznam šarží, sériových čísel.frx
Here's my pjm started from blank project created in Vfp 9 Sp2. (sorry for the d) It works with VSTS (or VSO). Checking in/out new files, Update project List works smoothly. Can you compare it with yours? Just like jessehouwing's answer, please make sure it's your workspace is server workspace.
Version= 1.20
Author=
Company=
Address=
City=
State=
Zip=
Country=
SaveCode=.T.
Debug=.T.
Encrypt=.F.
NoLogo=.F.
CommentStyle=1
Comments=
CompanyName=
FileDescription=
LegalCopyright=
LegalTrademarks=
ProductName=
Major=
Minor=
Revision=
AutoIncrement=.F.
[OLEServers]
[OLEServersEnd]
[ProjectFiles]
1218598277,K,vfpintegration2.scx,.F.,.T.,1252,,,
1218598357,P,vfpintegration2.prg,.F.,.F.,1252,,,
1218598458,P,vfpintegration2hello.prg,.F.,.F.,1252,,,
[EOF]
Also check the steps in my comment from
How to use Visual Studio Online source control with VFP 9 SP1
I downloaded and installed the Delphi 10 trial. However, every time I try to build anything at all, I get this: MSBuildToolsPath is not specified for the ToolsVersion "12.0" defined at "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0", or the value specified evaluated to the empty string
The 12.0 key does not exist within "ToolsVersions" on my pc. I do however have 2.0, 3.5, 4.0 and 14.0. I also have a full, perfectly-working installation of Visual Studio 2015 Community, if that knowledge helps. I am running Windows 10 Pro, 64-Bit. What can I do to correct this issue? It's the first time I've ever had a problem with any version of Delphi/RAD Studio... was actually not aware the Rad Studio IDE cared about or used or had anything to do with MSBuild until now.
It is a known issue, documented here:
https://community.embarcadero.com/article/technical-articles/16202-msbuildtoolspath-is-not-specified-for-the-toolsversion
This error is caused by incorrect values in the registry. On a 32 OS, run regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild. On a 64 bit OS, run regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild. First, backup this registry key by selecting File | Export. Next, look at the numbers below the ToolsVersions key. Delete any number not found at the MSBuild level.
...
There is anecdotal evidence to suggest this registry key imbalance is caused by uninstalling some versions of Visual Studio, but it has not been confirmed at this time.
Since I've been installing/uninstalling various Visual Studio versions (including previews), guess it has indeed been caused by that
Error "A default tools version "2.0" was specified, but its definition could not be found." may appear then if you deleted the 2.0 key following the 1st article's advice. Solution for that one is to edit each value under MSBuild key in the registry locations mentioned for x32 and x64 and change DefaultToolsVersion to 14.0 or other highest MSBuild tools version that is installed
Note that on x64 machine you need to fix these two issues for both x32 and x64 registry locations, since the IDE is 32-bit process and if you fix x64 location only it will fail internally, underlining all Standard units at uses clause in your source code and showing “Cannot resolve unit name xx”
Also it may be useful to install this:
https://www.microsoft.com/en-us/download/confirmation.aspx?id=48159
This may also be useful to know (copying from https://msdn.microsoft.com/en-us/library/bb383985.aspx):
Order of Precedence
The order of precedence, from highest to lowest, used to determine the ToolsVersion is:
The ToolsVersion attribute on the MSBuild task used to build the project, if any.
The /toolsversion (or /tv) switch that's used in the msbuild.exe command, if any.
If the environment variable MSBUILDTREATALLTOOLSVERSIONSASCURRENT is set, then use the current ToolsVersion.
If the environment variable MSBUILDTREATHIGHERTOOLSVERSIONASCURRENT is set and the ToolsVersion defined in the project file is greater than the current ToolsVersion, use the current ToolsVersion.
If the environment variable MSBUILDLEGACYDEFAULTTOOLSVERSION is set, or if ToolsVersion is not set, then the following steps are used:
The ToolsVersion attribute of the Project element of the project file. If this attribute doesn’t exist, it is assumed to be the current version.
The default tools version in the MSBuild.exe.config file.
The default tools version in the registry. For more information, see Standard and Custom Toolset Configurations.
If the environment variable MSBUILDLEGACYDEFAULTTOOLSVERSION is not set, then the following steps are used:
If the environment variable MSBUILDDEFAULTTOOLSVERSION is set to a ToolsVersion that exists, use it.
If DefaultOverrideToolsVersion is set in MSBuild.exe.config, use it.
If DefaultOverrideToolsVersion is set in the registry, use it.
Otherwise, use the current ToolsVersion.
I resolve my problem in delphi that need the Msbuild 14, i just download and install the msbuild that match my error message, in my case:
https://www.microsoft.com/en-us/download/details.aspx?id=48159
i think that you could download the msbuild from microsoft site to see if it works.
I'm new to MSI's. I've created a Window's Service that is the output project for my MSI. My local machine is a 64-bit Win 7 machine. The server I am trying to install on is a Win 2008 32-bit server running on a VM. I'm using .NET 4 VS2010.
Currently, my service's exe is building as a release target = Any CPU in the Config Manager. The MSI, does not give me any option to change the platform.
I can install no problem on my local 64-bit Win7 machine. However, whenever I try to install on the 32-bit Win 2008 I get the following error:
"This installation package is not supported by this processor type error. Contact your product vendor."
I tried changing the service's target to x86 rebuilding the exe and the setup, but I get the same result. The service references a number of class libraries. I changed those from Any Cpu to x86 as well just to see if that made any difference.
I also, made sure that my Setup project and Service Prerequisites are set to .NET Framework 4 (x86 and x64). I also experimented with changing the Prerequisites Windows Installer from 3.1 to 4.5.
Nothing seems to work. Any ideas? Thanks.
In my case, having entries specified under the HKLM/SOFTWARE (64-Bit) registry node was enough to cause installation failure on a 32bit Win7 host.
The symptoms were the same for VS 2010/2013 using the free, integrated InstallShield product. I was able to keep the Any CPU settings on the project being installed. There were no other special settings required for the MSI setup project.
OK, I figured out where the TargetPlatform is. It is different than on other VS Projects.
To access the TargetPlatform, select the MSI project and press the F4 key. Viola! Within the "Properties" grid, you will find the TargetPlatform field with options: x86, x64, Itanium. NOTE: this is a completely different set of properties that you get when you Right-Click on a project and select the "Properties (Alt-Enter)" item from the context menu. "Alt-Enter" Properties vs "F4" Properties.
Unfortunately, this is different than the other VS Project properties. Typically, Project Properties are set in the Main Window, not here in the "F4" properties grid. Hence, I kept getting confused when other threads discussed the properties of the project since this is different.
such as this one
ConfigurationManager in VS does not affect the MSI. I'm keeping all my dependent assemblies on "Any CPU". Also, don't forget target the correct framework in the "Launch Conditions" Window (right-click project -> View -> TargetConditions).
Hope this helps.
I am kind of late to answer this question! F4 does not work on Visual Studio 2017. Just highlight the Setup project, then right-click on Properties-tab on the RIGHT side-bar. Then change the "TargetPlatform" to your desired option. Please, note: This is different from right-clicking on the Setup project.
I try to load a F# project with Visual basic 2011 beta and I have the following issue, which appears for the first time :
There is a missing project subtype.
Subtype: '{5B89FCC2-C9F6-49a8-8F8D-EDDCC3FDC9E9}' is unsupported by this installation
Do you know how I can solve this problem?
At some point (VS2010?) you installed the FsProjectExtender to get some extra functionality available to F# projects in Visual Studio. Just re-install that extension again for VS2011 and you should be OK, or remove the dependency in the .fsproj file as noted by #Brian.
I don't know what that guid is for (Bing search did not turn up much), so you might simply try removing it from the ProjectTypeGuids in the .fsproj file (leaving only f2a71f9b-5d33-465a-a702-920d77279786 which is for the F# project system).