allykzam/amazingant.fsharp.typeexpansion

Code generation tool that applies expansion functions to simple types

amazingant.fsharp.typeexpansion's Issues

Current handling of WorkingDirectory parameter leaves unexpected files sometimes

Working with multiple projects in a solution still, and sometimes seeing an expanded file show up in the wrong working directory. Luckily I have git to tell me this! The type provider is likely being called to do its thing multiple times in short succession, and is getting the current directory set twice before code has a chance to finish. Will need to work up some proper file path handling instead.

Fix user compiler flags not being passed during intermediate builds

It would be nice to define a symbol like TYPE_EXPANSION or something so that code can do something like:

match thing with
...

#if TYPE_EXPANSION
| _ -> failwithf "Haven't written code for this match yet"
#endif

Add ability to include a `#load` when the output is an fsx file

When outputting an fsx file, it would be helpful to be able to automatically add #load "source_file.fsx" where source_file.fsx is the file that the original types came from. Initially going to use this with amazingant/Amazingant.FSharp.TypeExpansion.Templates#8 so that the expanded file is valid without being part of a project.

Add README note about including output source and rebuilding

During some of my dogfooding adventures, noticed that running build on a project that uses the provider, in the event that the provider runs and makes changes to the expanded source file, the finished binary for the project contains an outdated copy of the expanded source. Should make a note about this in the README, since it is unlikely to be something that can be worked around by the provider.

Compiler warnings during compilation are thrown as exceptions by the provider

Not sure how to handle this while still feeding the warnings to the user

Dependency on FSharp.Compiler.Service requires specific Microsoft.Build.Framework?

Everything seems to work fine on my development machine at work, and my home desktop, but when building a project on my laptop, I get errors complaining that Microsoft.Build.Framework cannot be found. Options are to figure out what version is needed and how I got it on some systems but not others, or to look for fsc.exe on the local system and stop depending on FSharp.Compiler.Service. And since it currently seems to lack some features, I'm leaning towards the latter.

Exceptions thrown when calling an expander are wrapped up in a TargetInvocationException

Need to catch them and re-throw so that the user knows what happened. The inner exception appears to contain a stack trace which may be useful to the user, but it does not include source lines. Should probably investigate adding debugging symbols to improve that?

Split files/references/etc. on line breaks in addition to commas

Would make it easier to write a list of file paths

Source path is less than helpful in multi-project solutions

If the type provider is used in multiple projects within a solution, the current working directory seems to be based on whichever project Visual Studio loaded the type provider for first. Since __SOURCE_DIRECTORY__ appears to be an acceptable static parameter, an optional static parameter should be added to allow specifying the target working directory. Error messages relating to file path should be adjusted to mention that this parameter is available (in case the specified path does not look like the path the user expects), and all input files and references as well as the output results should be adjusted to be relative to the specified path, if it is provided.

Automatically exclude files that use this library

The way I am using this involves pointing the source parameter to the current project file, and then adding an exclusion for the file that uses the type provider. It would be nice if the exclusion for those file(s) that use the type provider could be automatically generated? But given the name of the provider (Expand) and the ability to open namespaces, it could be rather difficult to decide which file(s) are using the provider?

Add paths for FSharp.Core and fsc.exe for F# 4.1

FSharp.Core version 4.1.0 has been released as a NuGet package; should update the FSharp.Core detection to handle this. And while doing so, may as well add in paths for the new fsc.exe as well.

Add a license?

Will probably use LGPL again? Using that in most of my other projects.

Update to support use from .NET Core

As part of migrating my projects at work to .NET Core, this tool needs to be updated. At the moment, the changes I've made that appear to function as needed mean altering the attributes assembly to target netstandard2.0, updating the design-time code with the type provider to net47, and adjusting calls to fsc to include a reference to netstandard. Still need to figure out the packaging, but I'll get that figured out shortly.

Type provider blows up on 32-bit Windows?

Forgot that the build server at $Employer is still running a 32-bit Windows OS. Whoops

Put a sane limit on how long fsc.exe can run in the background

Had an issue earlier where fsc decided to run indefinitely, and after closing out Visual Studio, devenv.exe and fsc.exe were still running in the background. Rather than calling WaitForExit() on the process for fsc.exe, should call WaitForExit(milliseconds:int) instead, and kill fsc if it takes longer than some sane length of time. Hopefully nobody runs this type provider on an old 386 etc., or it may time out on them.

Expand platform support

Playing around with things in Visual Studio for Mac and this type provider is being grumpy. Since I do not have a working mono/F# setup on any of my linux systems, I will not be able to fully test that, but should be able to at least get it up-and-running on the Mac? Hopefully 😬

Compiler timeout is not being passed to `runFsc` when building the dummy library

If anyone else is actually looking at these little changes, yes, I'm having a bad day.

Add header to generated source files

Similar to the big code block at the top of some files that are generated by Visual Studio, it would be helpful to put a header that indicates that the source file has been generated and should not be modified.

Handle empty expanded source code

If the source file(s) specified when using the type provider do not actually provide any expanded results, a cryptic compiler error is returned pointing to a temp file. Somewhere in the buildFinalAssembly function, the type provider should either handle this by maybe omitting the expanded source or maybe padding it with something useless that will compile, or should provide a useful error message indicating that nothing has been expanded.

Update to FSharp.Core 4.1.0

Add support for using a project file as the source

The README and some of the XML documentation currently indicates that this support exists when -- SURPRISE! -- it doesn't.