4

This is probably a bug, but I have 2 F# projects in my solution. One is a console app, the other is a test app (expecto test so technically also console). There are also 3 other C# projects in the solution.

When ever I build my solution the app.config in the startup project is not copied to the foo.exe.config. Instead a default F# config file is created and placed there.

The file that is being generated looks like this 

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.4.0.0" newVersion="4.4.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

None of the application configs in my solution look even remotely like that. I've checked that my app.configs are set to content mode. Also this is just a problem with the main application; the test app copies app.config into it's bin/debug just fine.

I've resorted to opening bin and dragging and dropping the correct exe.config into the directory every time before I want to run the program. I have no idea where to even begin to look to figure out what is probably not configured properly.

WhiteleyJ
  • 1,393
  • 1
  • 22
  • 29
  • Consider providing with more details on your solution. It would be hard to reproduce it by guessing. – Be Brave Be Like Ukraine Jan 27 '17 at 21:51
  • This looks like what `Paket` would generate if you asked it nicely. But I can't tell you exactly where this file comes from without seeing your project files. Chances are, there is something somewhere you're not noticing. – Fyodor Soikin Jan 27 '17 at 21:57
  • I don't think you need to mark app.config as content - in fact the default properties when you create a fresh F# console application are none/do not copy (and the dedicated task buried somewhere in the default `.targets` file explicitly copies and renames it). – scrwtp Jan 27 '17 at 22:09
  • I just had the same issue, but was copied in Release mode. Still didn't find out why. – Gus Jan 28 '17 at 07:50
  • Still not sure of the solution to this. I suspect it has something to do with a weird bug in visual studio related to swapping between C# and F# startup projects frequently. My solution was to create a separate sln for just the F# projects and not switch startup projects back and forth. From there on out things seem to be working properly. – WhiteleyJ Feb 07 '17 at 16:07
  • For some reason reason msbuild couldn't clean up a default config file that was generated in obj\Debug\Crawler.fsproj.Crawler.exe.config. At some point it got stuck there. I went in and hand deleted it and everything is working as normal now. – WhiteleyJ Feb 13 '17 at 17:38

1 Answers1

3

Why do you think it's a bug? Thousands of app.configs get copied every second - you'd assume that's rather well tested. There's probably something wrong with how your project is set up. You might want to look into the project file (hint: it's a regular xml file that you can read).

If you're building your project through VS, I'd suggest you bump up MSBuild verbosity first (Tools -> Options -> Projects and Solutions -> Build and Run tab).

Once you've done that, clean and rebuild your project. You should be able to find output from the task that copies the app.config file in the Build Output window when you search for CopyAppConfigFile. This should tell you what, if anything, really gets copied - and from where.

In a same way you can find if any other task that is part of your build process tries overwriting the file for whatever reason - as long as it produces proper log output.

scrwtp
  • 13,437
  • 2
  • 26
  • 30
  • bumping up MSBuild (files) verbosity ... hardly possible ;-) – robkuz Jan 28 '17 at 15:43
  • @robkuz: You haven't seen what I've seen... ;) – scrwtp Jan 28 '17 at 17:10
  • 2
    For some reason reason msbuild couldn't clean up a default config file that was generated in obj\Debug\Crawler.fsproj.Crawler.exe.config. At some point it got stuck there. I went in and hand deleted it and everything is working as normal now. – WhiteleyJ Feb 13 '17 at 17:38
  • 1
    @WhiteleyJ yeah I've had this as well. As you suspected, a bug. – Rob Grant Feb 11 '19 at 18:22
  • The answer was in the comments. Delete the obj folder because there was a file in there that couldn't be deleted. – WhiteleyJ Oct 24 '19 at 10:15