I've found solution to get C# / F# on travis: How do I use Travis-CI with C# or F#
except I get 3.2.4 version
I checked archive and found fsharpc there but can't find Microsoft.FSharp.Targets or something alike...
So... my Visual Studio F# project contains:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\FSharp\Microsoft.FSharp.Targets" />
And sure it will not work there... I was trying several ways including downloading Microsoft.FSharp.Targets from F# opensource github but then it was trying to use fsc instead fsharpc, that was a bit strange for me...
So in nutshell how should I make my fsproj file to be look like to make it work on MonoFramework provided by Xamarin ?
I don't use Visual Studio 2013 myself, but have helped another OSS project who did, get running on mono.
The current VS2013 fsproj has a conditional import for VS2012 (v11) for fsharp targets.
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
<PropertyGroup Condition="'$(VisualStudioVersion)' == '11.0'">
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
by adding an Or $(OS) != 'Windows_NT' this will work with xbuild of mono 3.2.4.
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
<PropertyGroup Condition="'$(VisualStudioVersion)' == '11.0' Or $(OS) != 'Windows_NT'">
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
Related
We've got a few delphi 10.4.2 projects, and anytime anything changes and the project is saved
<PropertyGroup Condition="('$(Platform)'=='Android' and '$(Base)'=='true') or '$(Base_Android)'!=''">
<Base_Android>true</Base_Android>
<CfgParent>Base</CfgParent>
<Base>true</Base>
</PropertyGroup>
<PropertyGroup Condition="('$(Platform)'=='Android64' and '$(Base)'=='true') or '$(Base_Android64)'!=''">
<Base_Android64>true</Base_Android64>
<CfgParent>Base</CfgParent>
<Base>true</Base>
</PropertyGroup>
And
<Platform value="Android">False</Platform>
<Platform value="Android64">False</Platform>
Keeps getting re-added to the project file.
I'd like to prevent this from happening, but see no obvious setting for this. Is there anything I'm missing, or is there no logical way to prevent this from happening while the Android tools are installed on the system? (and should only be used for 1 project, among the few hundred)
I am new to VS code/F# and I am trying to build a F# console app (on both Windows workstation and on my Linux computer).
I installed the Ionide extension together with FAKE.
The code I am considering is the Iris example (see How to translate the intro ML.Net demo to F#?), creating a New F# Project with Ionide and using Microsoft.ML.
My iris.fsproj is
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net461</TargetFramework>
<DebugType>portable</DebugType>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
</PropertyGroup>
<ItemGroup>
<Compile Include="iris.fs" />
<None Include="App.config" />
</ItemGroup>
<Import Project="..\.paket\Paket.Restore.targets" />
</Project>
When running the script (which I do with the "play" button aka F#: run script provided with VS Code/Ionide) I get:
C:\Users\MyUser\.nuget\packages\microsoft.ml\0.2.0\build\Microsoft.ML.targets(16,5): error : Microsoft.ML currently supports 'x64' processor architectures. Please ensure your application is targeting 'x64'.
together with
Running build failed.
Error:
System.Exception: dotnet build failed
How do I target x64 with the project structure provided by Ionide?
It should be as simple as adding the following line to your PropertyGroup section:
<PlatformTarget>x64</PlatformTarget>
There are more complicated setups possible using the Condition attribute to set the platform target based on various command-line arguments to the compiler, but that should be the simplest way to get you up and running.
I checked the middle option, below, "Precompile during publishing".
This changed the FDeploy.pubxml file by a few lines. Fine. I committed this single change to my build server.
Heres the pubxml:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>C:\Temp</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>False</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>DonotMerge</WDPMergeOption>
</PropertyGroup>
</Project>
The remote build with mvcbuildviews enabled passed. The remote deploy failed with errors like:
Error 82 The name 'ViewBag' does not exist in the current context
Error 5 The name 'model' does not exist in the current context
and so on. There's over 100 errors like this. Keep in mind the regular msbuildviews enabled msbuild step worked fine with the same code.
I use msbuild on the web project csproj this way:
/p:DeployOnBuild=true /p:PublishProfile=FDeploy /p:VisualStudioVersion=12.0 /p:Configuration=Release
Any clues? Oh yeah, checking the box caused the same errors on my dev machine as well, I had to delete the bin, obj and appdata folders completely to neutralize it. However, doing a fresh checkout on the build server did not help.
Also note that when I went back to my old deploy profile it took a fresh checkout to fix the deploy.
I had to cheat to solve this problem: I restricted my use of MvcBuildViews to only the 'Debug' version of the project:
In the csproj file:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<MvcBuildViews>true</MvcBuildViews>
</PropertyGroup>
I ran into other inexplicable errors using mvcbuildviews when deploying. Seems best to avoid using it altogether. Anyway, the build is still kept clean because I compile and test the debug version too.
I wish to call the GetBuildProperties task from my MSBuild script run on TFS.
However, this script can be run on either TFS 2010 or TFS 2013.
Is there a way to detect the version of TFS that has launched an MSBuild Script? At the moment, I am getting around the problem like so:
<PropertyGroup>
<CurrentProgramFiles>$(ProgramW6432)</CurrentProgramFiles>
<CurrentProgramFiles Condition="$(CurrentProgramFiles) == ''">$(ProgramFiles)</CurrentProgramFiles>
</PropertyGroup>
<PropertyGroup Condition="$(TeamFoundationServerUrl)!='' and Exists('$(CurrentProgramFiles)\Microsoft Team Foundation Server 2010')">
<TeamBuildRefPath>$(CurrentProgramFiles)\Microsoft Team Foundation Server 2010\Tools</TeamBuildRefPath>
</PropertyGroup>
<PropertyGroup Condition="$(TeamFoundationServerUrl)!='' and Exists('$(CurrentProgramFiles)\Microsoft Team Foundation Server 12.0')">
<TeamBuildRefPath>$(CurrentProgramFiles)\Microsoft Team="" Foundation Server 12.0\Tools</TeamBuildRefPath>
</PropertyGroup>
<UsingTask
TaskName="Microsoft.TeamFoundation.Build.Tasks.GetBuildProperties"
AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.ProcessComponents.dll"
Condition="$(TeamFoundationServerUrl)!=''" />
Starting with TFS 2013 you have some interesting variables, not previously available TF_BUILD environment variables. So you can use TF_BUILD to know if you are using 2013, like this.
<PropertyGroup>
<IsTFS2013orHigher Condition="$(TF_BUILD)!=''>Yes</IsTFS2013orHigher>
</PropertyGroup>
For the install path I would peek the Registry
<PropertyGroup>
<TFS2013InstallPath>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TeamFoundationServer\12.0#InstallPath)</TFS2013InstallPath>
<TFS2012InstallPath>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TeamFoundationServer\11.0#InstallPath)</TFS2012InstallPath>
<TFSInstallPath Condition="'$(TFS2013InstallPath)'!=''">$(TFS2013InstallPath)</TFSInstallPath>
<TFSInstallPath Condition="'$(TFS2013InstallPath)'=='' and '$(TFS2012InstallPath)'!=''">$(TFS2012InstallPath)</TFSInstallPath>
</PropertyGroup>
Has anyone got a Web Deployment Project to work with ASP.NET MVC? When I open the "deployed" project, a lot of the files are missing that MVC requires and makes it tough to Publish to the server with all the missing files in the project.
Or... Is there a better way than a Web Deployment Project to modify the Web.Config for MVC apps? I have differences (SMTP and connection strings) that need to be updated before uploading and Web Deployment Projects seem to be the right method.
Thanks as always!
Update: I am missing at least global.asax, global.asax.cs, and default.aspx.cs.
Update 2: Once I Publish, I get this error. Could not load type 'AppNamespace._Default'.
I haven't set up a Deployment project yet with my mvc app but I've been using this technique outlined by Scott Hanselman and it works great.
Managing Multiple Configuration File Environments
The 3 specific files you have listed are all compiled into the binary produced by your ASP.NET MVC web project. Open up your .csproj and you will see:
<Compile Include="Global.asax.cs">
<DependentUpon>Global.asax</DependentUpon>
</Compile>
<Compile Include="Default.aspx.cs">
<DependentUpon>Default.aspx</DependentUpon>
<SubType>ASPXCodeBehind</SubType>
</Compile>
Open up your binary in a tool such as Reflector and you will see the classes. Therefore you don't need to deploy them.
These MSBuild steps in the MVC .csproj render part of what the Web Deployment Project does (i.e. compiling a single binary for the site) redundant.
As for the token replacement you can either keep your Deployment project or probably copy the relevant MSBuilds steps from your .wdproj file into your .csproj file. This is not something I've done, but am shortly to try myself.
I've found it working for me.
When you say there are files missing, are you talking about the System.Web.Mvc files and such? You need to make sure in your web application that these references are set to copy locally.
I have deployt succesfully to IIS6 using a Web Deployment Project.
I had issues deploying to Server 2003 first, but in my case it realy was a problem of the stage-environment.
I first deployt to a local IIS to check if it was a problem of the build or of the environment.
I did not use config - replacement.
This is my build script:
C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe "D:\Projekte\NiceProjectName\source\NiceProjectName_Build\NiceProjectName_Build.wdproj" /t:Build /p:Configuration=Release
Here is my wdp:
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>9.0.21022</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{E5E14CEB-0BCD-4203-9A5A-34ABA9C717EA}</ProjectGuid>
<SourceWebPhysicalPath>..\NiceProjectName</SourceWebPhysicalPath>
<SourceWebProject>{3E632DB6-6DB3-4BD0-8CCA-12DE67165B48}|NiceProjectName\NiceProjectName.csproj</SourceWebProject>
<SourceWebVirtualPath>/NiceProjectName.csproj</SourceWebVirtualPath>
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>.\Debug</OutputPath>
<EnableUpdateable>true</EnableUpdateable>
<UseMerge>true</UseMerge>
<SingleAssemblyName>NiceProjectName_Build</SingleAssemblyName>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugSymbols>false</DebugSymbols>
<OutputPath>..\..\deploy</OutputPath>
<EnableUpdateable>false</EnableUpdateable>
<UseMerge>true</UseMerge>
<SingleAssemblyName>NiceProjectName</SingleAssemblyName>
</PropertyGroup>
<ItemGroup>
</ItemGroup>
<Import Project="$(MSBuildExtensionsPath)\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets" />
</Project>