3.5k
views6
comments

Type-checking fsx script files when building a project / solution

Hi,

I've noticed that as the number of script files I have in my solution has grown, keeping them correct with respect to the libraries beneath them has become difficult.

Is there a way to type-check script files as part of the build process?

I'm an MsBuild newbie but worked around this by adding a custom .targets file to solution that calls the compiler on the scripts. Security considerations (of custom .targets) and the fact that compilation takes longer than type-checking and that no dependency analysis is done to allow for incremental builds makes this less than ideal.

For anyone in a similar situation I'll reproduce the .targets file:

FSharpCustom.targets

<ItemGroup>
<AvailableItemName Include="TypeCheck" />
</ItemGroup>

<TypeCheckNoWarn>191</TypeCheckNoWarn>
<TypeCheckOutputFile>$(IntermediateOutputPath)Script.exe</TypeCheckOutputFile>
<BuildDependsOn>
$(BuildDependsOn);TypeChecker
</BuildDependsOn>

<Message Text="Type-checking scripts @(TypeCheck->'%(Filename)%(Extension)')"
Importance="high" />
<Fsc Sources="@(TypeCheck)"
Optimize="False"
NoWarn="$(NoWarn);$(TypeCheckNoWarn)"
OutputAssembly="$(TypeCheckOutputFile)"/>
<WriteLinesToFile
File="$(IntermediateOutputPath)$(CleanFile)"
Lines="$(TypeCheckOutputFile)"
Overwrite="false"/>

</Target>

then any script you wish to type-check can be set in the Properties Window to:

Build Action: TypeCheck

Also you need to manually add an <Import> to the .fsproj file so:

<Import Project="..\Global\FSharpCustom.targets" />

I also noticed that all the classes in Micrsoft.FSharp.Compiler.dll are internal meaning that I couldn't attempt to type-check scripts rather than compile. What of compiler-as-a-service?

Any more elegant solutions would be very welcome... otherwise perhaps the FSharp team could allow for some kind of option like this.

many thanks,

Danny

There are probably a lot of possible solutions in this space, depending on exactly what your constraints/preferences are.

Just brainstorming, if you keep the scripts in the individual projects they are associated with as "None" BuildActions, but then also have a separate "CompiledScripts" project that has each script in the solution added as a linked file with a BuildAction of 'Compile'... how does that work out? The only 'duplication' is that you have to remember to add each new script to both its project and to the CompiledScripts project (you could probably use some MSBuild magic to get around that if desired - e.g. traverse all project references and find all the None Include="blah.fsx" files...).

Anyway, there are probably a few ways to slice this, I am happy to brainstorm.

(Compiler-as-a-service is still a long ways out from being delivered, for all the languages, I think?)

By brianmcn on 8/27/2009 10:56 AM (permalink)

Hi Brian,

many thanks for the quick response!

Obviously I'd prefer an 'enterprise' solution, i.e. one that doesn't require policing, and would be understood by a new developer opening a solution file for the first time (when the old developer is long gone.) Having a default Build Action of TypeCheck would seem to fulfill this.

TypeCheck would also allow a warning to be issued rather than a compile error (that broke the build.)

Could we brianstorm a solution to the build-time issue of compilation and dependency checking too? Having a solution compile 30 scripts ever time you press F5 is less than ideal.

btw - I did try to find a way to set the default Build Action of scripts to TypeCheck, but following this then this post, I found that the FSharp project system doesn't expose the correct AutomationEvents ( I believe CSharp exposes:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Packages\{FAE04EC1-301F-11D3-BF4B-00C04F79EFBC}\AutomationEvents\CSharpProjectItemsEvents

for instance)

thanks again,

Danny

By DannyAsher on 9/2/2009 10:13 AM (permalink)

I'm happy to report that in VS2010 Beta2 it will be possible to modify the build action of newly added files; the code below shows something that works on my box at work.

 
open EnvDTE
open EnvDTE80

let appObj = System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE") :?> EnvDTE80.DTE2
let projItemsEvents = (appObj.Events :?> Events2).ProjectItemsEvents
let listenerAdd (p : ProjectItem) = 
    printfn "Added: %s" p.Name
    async {
        do! Async.SwitchToThreadPool()
        System.Threading.Thread.Sleep(1000)
        p.Properties.Item("ItemType").Value <- box "MyOwnBuildActionChoice"
    } |> Async.Start
projItemsEvents.add_ItemAdded(_dispProjectItemsEvents_ItemAddedEventHandler(listenerAdd))

System.Console.ReadKey()

It is still klunky; the event fires at a time when the F# project system is still in the midst of its dance to re-organize the .fsproj file (stuff we do under the hood to support file ordering, 'Add Above', etc), and so I had to go off-thread and sleep to give the F# project system a chance to finish doing that before I went poking at the BuildAction. I think perhaps these ProjectItemsEvents didn't work in Beta1 (though try) and were only something we fixed or wired up properly recently (to appear in Beta2).

I'm still mulling over the rest (both from the point of view of what's possible, as well as what makes for a good user experience)...

By brianmcn on 9/6/2009 7:38 PM (permalink)

Regarding the rest, I think you're on the right track with your first message.

I think adding Inputs=... and Outputs=... to your custom "Target" will enable MSBuild to do dependency checking based on file timestamps and only re-cechk when necessary.

Regarding security of custom .targets, there are registry keys you can set on developer desktops to declare targets that are 'safe to import', e.g.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports

Regarding adding the "Import" to each project, you could create custom project templates.

I think perhaps all of those would be reasonable to do for the 'standard development environment' in your enterprise.

By brianmcn on 9/6/2009 7:48 PM (permalink)

Oh, and FYI, the general MSBuild mechanism to specify "custom build actions" that should appear in the BuildAction dropdown in the VS file-properties UI is to add

as items to the project. I can't recall if that works in Beta1 or not, but it will work moving forward.

By brianmcn on 9/6/2009 7:55 PM (permalink)

Hi Brian,

I really appreciate the detailed response and look forward to the fruits of the mull.

Good to know that AutomationEvents will be supported in Beta2. I've already added a bat script to add the custom .targets file to the SafeImports registry and <AvailableItemName Include="TypeCheck" /> is the first declaration in the custom .targets file above.

Manually adding Inputs and Outputs to the custom Target is exactly what I wanted to avoid. Obviously fsi.exe parses a script file, extracts the #r references and uses the msbuild resolution process to determine the location of the files. This is not something I want to replicate and maintain if at all possible! I'd prefer to give up type-checking on the desktop and use brute-force script compilation on the build server. However that would cause developers to unwittingly break the build when they checked in changes to library code without compiling the dependent script files. This would also distance the break from its fix.

To do this efficiently I would probably create a custom MsBuild task that copied the bit of fsi.exe that does the reference resolution and then type-check if necessary. This would probably put me into legal hot water with the license on fsi.exe.

Even if I took it on faith that the fsi.exe licence was turning MS-PL on release of VS10, the process does seem rather involved:

1) Create custom imports
2) Add to registry in SafeImports for each branch
3) Require custom add-in to override ProjectItem add
4) Write custom MsBuild task to do script dependency resolution and type checking.

This is not a burning issue now, but should F# development take off in my place of work, this looks to be a potential sore spot.

Anyhow, food for thought.

regards,

Danny

By DannyAsher on 9/7/2009 7:05 AM (permalink)

Topic tags

Built with WebSharper

Home

Answers

Events

Courses

Groups and Conferences

Blogs

Jobs

Developers

Topic tags