Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Making NCRUNCH aware of additional reference (for which there is no code, just dlls)
Options
Previous Topic Next Topic
bibsoconner
#1 Posted : Saturday, March 8, 2014 1:14:44 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 2/27/2014(UTC)
Posts: 7
Location: United States of America
I asked another question here:

http://forum.ncrunch.net...project-under-test.aspx

and got lots of valuable information. My question here is somewhat related but different enough that I felt it warranted a separate post.



I have added a test project to a solution given to me and wrote a very simple unit test. I can't easily modify the rest of the solution which uses lots of absolute paths instead of project references. I'm only adding a UnitTest dll. It would not pass with MSTest or NCrunch. It then passed AFTER I changed the output path of the UnitTest dll to be the same absolute path as the output path for the application under test.* This seems reasonable, the unit test dll has need of the same references as the app under test. Forcing the unit test dll to the same place as the main app allows it to find all those pesky references. I should mention that some of these references are just dlls. No source code.

The error I got until I made this fix was
System.TypeInitializationException: The type initializer for 'Frame.Presenters.MainWindowPresenter' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'ABC.dll' or one of its dependencies. The specified module could not be found.
at Frame.Presenters.MainWindowPresenter..cctor()
--- End of inner exception stack trace ---
at Frame.Presenters.MainWindowPresenter..ctor()
at FrameUnitTests.MainWindowPresenterTests.MainWindowPresenterTest() in C:\SVN\Frame_Mike\FrameUnitTests\MainWindowPresenterTests.cs:line 14#0

I believe the key problem is that this main project under test. "Frame" has absolute reference (not project reference and not relative references!) to stuff in:

C:\CompanyName\bin\Frame\3.0\Debug\ABC.dll

I can't easily change the structure of the solution, I'm simply adding a unit test project to it. Furthermore I should state that there is not code associated with ABC.dll, it is simply a dll that Frame project references.

As I said, I "fixed" the problem by making the output path for the unit test dll go to C:\CompanyName\bin\Frame\3.0\Debug. This isn't perfect though because I have to disable NCrunch to do a rebuild due to NCrunch and MSBuild conflicing (again see previous post if you are interested). In the referenced previous post it was suggested to have different output paths, one for the main build and one for NCrunch. Something like:

<OutputPath Condition="'$(NCrunch)' == '1'">bin\</OutputPath>
<OutputPath Condition="'$(NCrunch)' != '1'">$(OUTDIRECTORY)</OutputPath>

I tried this, but it doesn't seem to work here. If you let NCrunch put the unit test dll local, it doesn't know about all those references in: C:\CompanyName\bin\Frame\3.0\Debug I even tried have to paths for the project under test. Again, no luck. In this case, where I can't modify the solution and am just adding a unit test project it seems like the solution would be to use two above paths as described above (so rebuild alls can be done without disabling NCrunch) and also have a way of telling NCrunch, "oh by the way, all the references you need can be found in C:\CompanyName\bin\Frame\3.0\Debug".
Is there a way to do such a thing?

Thanks,
Dave

*For full disclosure I should mention that simply running the test from Test Explorer (i.e. no NCrunch was failing) until I changed Test->Test Settings->Default Processor Architecture to x64. After that no problems. Suspecting that might be NCrunch's problem too, I changed "Use CPU architecture" under NCrunch settings to "x64". No difference.

Edit...
I should also mention that with my "fix", besides the problem of rebuild all, the code coverage is not working. I.e. no stats on amount of code covered by tests.
Back to top
 |  Edit by user
Remco
#2 Posted : Saturday, March 8, 2014 1:31:11 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi, great to hear you've been making some progress with NCrunch on this challenging solution.

Can you share any details on how the ABC.dll project is being referenced from the "Frame" project? You've mentioned that this is an absolute reference - is this path declared in the MSBuild XML? For example:
<Reference Include="C:\CompanyName\bin\Frame\3.0\Debug\ABC.dll" />

Can you also share how this reference is resolved at run time? Is there any use of reflection to load it into the process? i.e. Assembly.LoadFrom? Or is the code just relying on the usual CLR logic of resolving assemblies as they are needed?

Finally, how are you referencing the "Frame" project from your new unit test project? Is this being done using a ProjectReference or assembly Reference?
Back to top
bibsoconner
#3 Posted : Thursday, March 13, 2014 9:08:56 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 2/27/2014(UTC)
Posts: 7
Location: United States of America
Remco,

Thanks for the reply and sorry about my late reply. I was diverted to other projects. The good news is that we have bought some NCrunch licenses. NCrunch has been quite useful to us.

To answer your questions:

Abc project is being referenced from main frame project (the actual app) like this:

<Reference Include="ABC, Version=1.0.0.0, Culture=neutral, processorArchitecture=AMD64">
<SpecificVersion>False</SpecificVersion>
<HintPath>$(FRAME_BUILD)\Debug\ABC.dll</HintPath>
</Reference>

This is taken from the actual project file for Frame. Remember, there are a few references like ABC.dll and for some of them I really don't even have the source code! ABC.dll "lives"
only in $(FRAME_BUILD)

Incidentally, the Output path for Frame is defined as:

<OutputPath Condition="'$(NCrunch)' == '1'">bin\Debug</OutputPath> // Release version is similar
<OutputPath Condition="'$(NCrunch)' != '1'">$(FRAME_BUILD)\Debug\</OutputPath>

You'll note your idea (from the previous post) of using NCrunch variable.

For the actuall unit test project I refer to Frame as:

<ItemGroup>
<ProjectReference Include="..\Frame\Frame.csproj">
<Project>{d8430509-f705-41be-b5fb-a4d55c3dfdc7}</Project>
<Name>Frame</Name>
</ProjectReference>
</ItemGroup>

That is, it's a project reference. For completeness, here's the output path for the unit test project:

<OutputPath>$(FRAME_BUILD)\Debug</OutputPath> Notice that the dll is put to the same output path as Frame. Again, when the ouptut path was just local, I got the error about

The type initializer for 'Frame.Presenters.MainWindowPresenter' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'ABC.dll' or one of its dependencies. The specified module could not be found.


Is this enough information? Any help is much appreciated. I just got back to this project and was momentarilly startled to see no code coverage. Of course there is coverage. That was
just one of the symptoms I initially reported: code metrics are messed up.

Thanks,

Dave
Back to top
Remco
#4 Posted : Thursday, March 13, 2014 10:49:41 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi Dave,

Thanks for coming back to this one, and for buying licenses for NCrunch.

I think I can give you a solution that will allow the code here to run using NCrunch, but it will suffer from several problems including loss of code coverage over the ABC.dll.

By turning on the 'Copy referenced assemblies to workspace' project-level NCrunch configuration setting for ALL the projects in your solution (just multi-select using the config tree), NCrunch will start copying referenced assemblies into the build output directories of each of the projects it builds. This means that your projects should be able to find their dependencies at run-time inside the NCrunch workspace, without needing to be placed in your absolute outputpath directory.

Unfortunately though, without replacing the <Reference> tags with <ProjectReference> tags inside your build XML, NCrunch will still be linking your projects to the output assemblies in your foreground solution, instead of linking them to each other. This means that you'll lose code coverage for these projects and NCrunch will be unable to capture changes made to them (from the perspective of dependencies) until you rebuild your foreground solution.

To make NCrunch fully work with this solution, you'll need to make the same changes to your other projects (i.e. using the ProjectReference tag> as you have with your new unit test project. It IS possible to make these NCrunch-specific by using the $(NCrunch) environment variable, for example:

<Reference Include="C:\CompanyName\bin\Frame\3.0\Debug\Frame.dll" Condition="$(NCrunch) == '0'" />

<ProjectReference Include="..\Frame\Frame.csproj" Condition="$(NCrunch) == '1'">
<Project>{d8430509-f705-41be-b5fb-a4d55c3dfdc7}</Project>
<Name>Frame</Name>
</ProjectReference>

... However, this would be a nightmare to maintain and would probably cause grief if your coworkers are not using NCrunch, since you'll constantly need to fix up changes in project referencing.
Back to top
 |  Edit by user
Remco
#5 Posted : Friday, March 14, 2014 6:21:00 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi Dave -

I've been dwelling on this one a bit since my last post, and I think I may be able to offer you a technical solution that won't involve changing your existing project structure.

I've been experimenting with a new solution-level configuration setting, 'Infer project references using assembly names', which when turned on will trigger NCrunch to infer project references using the assembly references of projects in your solution. This means that NCrunch will logically swap out the <Reference> elements for <ProjectReference> internally, where it detects projects within the solution that have an output assembly name identical to the referenced assembly.

You're welcome to give it a try. I'm keen to hear if it solves the problem for you. This does come with some warning that the setting is still experimental. There may be angles here that I haven't considered.. so definitely let me know if it falls flat on its face.

http://downloads.ncrunch.net/NCrunch_GridNodeServer_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_GridNodeServer_2.6.0.4.zip
http://downloads.ncrunch.net/NCrunch_VS2008_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_VS2010_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_VS2010_2.6.0.4.zip
http://downloads.ncrunch.net/NCrunch_VS2012_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_VS2012_2.6.0.4.zip
http://downloads.ncrunch.net/NCrunch_VS2013_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_VS2013_2.6.0.4.zip

This build also has a new feature that allows you to specify environment variables inside NCrunch controlled processes. I'm thinking you might be able to make use of this to override your $(OUTDIRECTORY) variable with a different relative path inside the NCrunch environment. This feature was released in V2.5 but it had some problems have have been corrected in the above build.

Between the new project inference configuration setting and the custom environment variable option, I think it should be possible to have your entire solution work with NCrunch without requiring any hacks or overrides.
Back to top
iceypoi
#7 Posted : Friday, March 14, 2014 9:14:12 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/14/2014(UTC)
Posts: 5

Was thanked: 1 time(s) in 1 post(s)
I have what feels like a similar issue. When using FSharp.Data (an F# type provider assembly), NCrunch fails to build, because the type provider during BUILD time has an additional dependency, namely FSharp.Data.DesignTime. A simple work-around is to actually reference the latter in my productive code, but since the assembly is never used during run time i'd like to avoid that.

When you get FSharp.Data from nuget, it comes with both assemblies, but you only reference the one you acutally need in your productive code, i.e. FSharp.Data but not FSharp.Data.DesignTime. As I looked at the NCrunch temp folders, I saw that it only copied FSharp.Data and not FSharp.Data.DesignTime.

I suppose there is no way to somehow add an implicit assembly reference? Kind of like implicit project reference, but for assemblies.
Back to top
Remco
#8 Posted : Friday, March 14, 2014 9:51:01 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi -

The issue you've described sounds like an implicit dependency on FSharp.Data.DesignTime and can probably be solved by turning on the Copy referenced assemblies to workspace setting for the projects involved.

Is it the test project that is having difficulty building? Or the production project?
Back to top
iceypoi
#9 Posted : Saturday, March 15, 2014 9:07:09 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/14/2014(UTC)
Posts: 5

Was thanked: 1 time(s) in 1 post(s)
Hi Remco,

ok... so the dependencies are thus (already the production code break, but i'm pretty sure the test code will break too, since it also uses the type provider):

Code:
FileReader (productive code) ===> FSharp.Data

FileReader                   =/=> FSharp.Data.DesignTime
FSharp.Data.DesignTime       =/=> FSharp.Data
FSharp.Data                  =/=> FSharp.Data.DesignTime


Basically FSharp.Data and FSharp.Data.DesignTime are not referenced at all between each other.

The culprit will be this code FSharp.Data/src/Runtime.fs

The TypeProviderAssemblyAttribute informs the F# compiler of a type provider which is really a compiler plug-in for this one compilation. It also allows you to define a different assembly as the assembly used by the compiler during design time only, it is never executed at runtime. Which is exactly what they have done, so that the productive code does not carry around dead designer code.

As such the copy referenced assemblies als does not help, since the assemblies are not referenced.

I think the correct way of fixing it, would be to look for the TypeProviderAssemblyAttribute and copy along the design time assembly if it specified. And actually looking for this attribute is correct, because the attribute is baked into the compiler.

If this is not feasible or too much work, a nice work around would be to provide the possiblity to manually add files to the _ncrunchreferences.
Back to top
 |  Edit by user
1 user thanked iceypoi for this useful post.
Alexander on 10/30/2016(UTC)
Remco
#10 Posted : Saturday, March 15, 2014 11:39:31 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
I think that there's a couple of options for how you can work around this. Probably the simplest option would be to include references from both the production and test projects to the FSharp.Data.DesignTime assembly, then make these references 'NCrunch only'. For example:

<Reference Include="FSharp.Data.DesignTime" Condition="$(NCrunch) == '1'">
<HintPath>..\References\FSharp.Data.DesignTime</HintPath>
</Reference>

An alternative option would be to introduce a pre-build event that is executed by NCrunch for each of these projects, which copies the design-time DLL into the _ncrunchreferences directory. You can add the design-time DLL to NCrunch's 'Additional files to include' setting so that it is always in a consistent place inside the workspace where it can be copied from.

In fact, it may even be possible to just create a directory called '_ncrunchreferences' inside each of the projects, place the FSharp.Data.DesignTime.dll file inside this directory, then add this file to the 'Additional files to include' setting. In theory, the file should land inside the workspace at the right location and it should just work ... I have no easy way to test this, but it could be worth a try.
Back to top
1 user thanked Remco for this useful post.
Alexander on 10/30/2016(UTC)
iceypoi
#12 Posted : Saturday, March 15, 2014 2:34:26 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/14/2014(UTC)
Posts: 5

Was thanked: 1 time(s) in 1 post(s)
I tried the first option and it works like a charm :-) It also feels pretty clean, given that the nuget packages does nothing with the FSharp.Data.DesignTime reference.

However, I also made a trivial mini solution, that is capable of reproducing the problem https://github.com/DanielFabian/NCrunchReproduce

Just in case you want to look into solving the case more generally for type providers. Type providers are very, very popular amongst F# guys, even to the point where they can be the tipping point for selling F# to customers as a developping platform.

On our team of F# developers, we tested NCrunch recently and now are actually going for it.

At some later point, I might need to find out if it is possible to run the NCrunch distributed processing nodes as an exe rather than a service - we do GPU computing and those typically do not play nicely with services. But one step at a time.

Anyway, thanks for the help.
Back to top
Remco
#13 Posted : Saturday, March 15, 2014 9:30:47 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Great to hear. Thanks so much for the reproducing code sample - I'll use this to see if I can provide a better way to handle this situation.

Do get in touch if/when you have issues with the GPU computing and we'll see if we can work out a solution. There isn't any built-in way to make the service run as a .exe, but I'm a little confused about this limitation and think there may still be a way to make it work (the task runners themselves are simple .exes).
Back to top
iceypoi
#14 Posted : Sunday, March 16, 2014 7:31:24 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/14/2014(UTC)
Posts: 5

Was thanked: 1 time(s) in 1 post(s)
It has to do with the GPU driver. With the exception of some industrial GPUs (we only have like 1-2), the driver only allows you to use the GPU if you physically are logged in, no RDP, no being logged out and run as service in another user's context, etc.

What does work, is accessing the computer with some sort of remote control software like TeamViewer or somehow run as the currently logged in user.

This is what we do with TeamCity: We have the build agents set up so, that they log in on start up and TeamCity is not run as a service, but rather as an exe. I.e. you literarily see some window on the desktop if you log in.
With TeamCity it is easy, because internally whenever it is run as a service, it really is a wrapper around a normal java exe and so you can also just run the java exe instead.
Back to top
Remco
#15 Posted : Sunday, March 16, 2014 10:13:27 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Does it work with a service that's set to log in as the local user, and set to interact with the desktop? (i.e. controlled by the settings under the service properties).
Back to top
iceypoi
#16 Posted : Sunday, March 16, 2014 10:59:22 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/14/2014(UTC)
Posts: 5

Was thanked: 1 time(s) in 1 post(s)
No, unfortunately not, I just tried again. The problem is a so called Session 0 isolation. In short, you can only access a GPU if you are working from Session 0 or you have a special GPU with a special Driver, e.g. Tesla k40.

The work around is to automatically log in to windows and run all "services" as normal applications.

Maybe in a future version, you could provide a wrapper or the option to pass in a command line argument to not run as a service, but interactively, instead. There is no need for any output or anything, just that we cannot run GPU tests if the executing code is run from the different session.
Back to top
 |  Edit by user
Remco
#17 Posted : Sunday, March 16, 2014 11:06:02 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
I agree that a console wrapper seems like the simplest solution. I can probably rig this up with some log output too, just so it is a bit more flexible and people can also use it for other purposes. It may also be useful for my own testing. Thanks for the suggestion - I'll see what I can do.
Back to top
bibsoconner
#6 Posted : Monday, March 24, 2014 11:13:57 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 2/27/2014(UTC)
Posts: 7
Location: United States of America
Remco, I tried your suggestion of turning on 'Infer project references using assembly names'. It made no difference. I'm not sure I understand what you mean by "environment variables..." that you refer to at the end of your posting. I'd need to see an example.

Thanks,
Dave
Remco;5538 wrote:
Hi Dave -

I've been dwelling on this one a bit since my last post, and I think I may be able to offer you a technical solution that won't involve changing your existing project structure.

I've been experimenting with a new solution-level configuration setting, 'Infer project references using assembly names', which when turned on will trigger NCrunch to infer project references using the assembly references of projects in your solution. This means that NCrunch will logically swap out the <Reference> elements for <ProjectReference> internally, where it detects projects within the solution that have an output assembly name identical to the referenced assembly.

You're welcome to give it a try. I'm keen to hear if it solves the problem for you. This does come with some warning that the setting is still experimental. There may be angles here that I haven't considered.. so definitely let me know if it falls flat on its face.

http://downloads.ncrunch.net/NCrunch_GridNodeServer_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_GridNodeServer_2.6.0.4.zip
http://downloads.ncrunch.net/NCrunch_VS2008_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_VS2010_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_VS2010_2.6.0.4.zip
http://downloads.ncrunch.net/NCrunch_VS2012_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_VS2012_2.6.0.4.zip
http://downloads.ncrunch.net/NCrunch_VS2013_2.6.0.4.msi
http://downloads.ncrunch.net/NCrunch_VS2013_2.6.0.4.zip

This build also has a new feature that allows you to specify environment variables inside NCrunch controlled processes. I'm thinking you might be able to make use of this to override your $(OUTDIRECTORY) variable with a different relative path inside the NCrunch environment. This feature was released in V2.5 but it had some problems have have been corrected in the above build.

Between the new project inference configuration setting and the custom environment variable option, I think it should be possible to have your entire solution work with NCrunch without requiring any hacks or overrides.
Back to top
Remco
#18 Posted : Tuesday, March 25, 2014 2:14:39 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi Dave,

Is there any chance you could submit a bug report after the NCrunch engine has initialised with the 'Infer project references' option turned on? I'm not sure why this isn't working for you .. but it is new and experimental. Hopefully the bug report will yield some interesting information.

For the environment variable, I suggest setting up a custom environment variable under the name 'OUTDIRECTORY' with the value 'bin'. This will encourage your build to work using relative paths in NCrunch and will prevent the file locking issues you've been experiencing, without the need to modify project files to specify a special output path for NCrunch.
Back to top
bibsoconner
#19 Posted : Tuesday, March 25, 2014 4:40:19 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 2/27/2014(UTC)
Posts: 7
Location: United States of America
Hi Remco,

I think the best thing to do is for me to carve aside some time and come up with a demo project. Unfortunately, I can't just send over our work. I don't think I'm sufficiently explaining our setup. You keep referring to a "solution". In fact we have multiple solutions with multiple projects. All the libs, exes go to a central directory defined by an environmental variable. I had good luck with NCrunch testing my own work. That is, I have a solution with a class library. I have added a unit test project to that and successfully tested it (code coverage, etc. all works). I have another solution consisting of some UserControls (written as Views and ViewModels). This solution makes use of the class library mentioned. Again, no problems. Now, my boss wants me to test the "main app" or at least some parts of the main app (presenter, viewmodels). This main app is in its own solution and makes use of my stuff, other peoples work (that is in other solutions) and even class libraries that we don't have the source code for. Possibly your first idea of modifying everyone else solution to use something like:

<Reference Include="C:\CompanyName\bin\Frame\3.0\Debug\Reference.dll" Condition="$(NCrunch) == '0'" />
<ProjectReference Include="..\Reference\Reference.csproj" Condition="$(NCrunch) == '1'">
would work. I'd also have to change the output paths to use relative paths? Of course, this isn't a great solution for 2 reasons: I have to change other peoples work, and most importantly, I don't have access to .csproj files for some of the class libraries. I just have the .lib files.

Re your request for a bug report....
1) How do I capture a bug report? I.e. what is it you want to see? The output window?
2) How do I submit it?

Perhaps you could also tell me how to submit some simple code examples. I'll need to come up with 2 or 3 separate solutions that use an environment variable.

Thanks!

Dave
Back to top
Remco
#20 Posted : Tuesday, March 25, 2014 10:01:25 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi Dave,

If there's any way you can create a code sample, that would be enormously helpful. I can then give you specific instructions (or a build of NCrunch) that will make this sample project work. Assuming the problems are the same between the sample project and your real world project, the real world project will work too. You can submit code through the contact form at https://www.ncrunch.net/Support/Contact.

To submit a bug report, just choose the 'Submit Bug Report' option from the 'NCrunch' menu in your IDE. Make sure you do this just after the engine has initialised. The log file that goes with the bug report has limited capacity, so the closer we can get to the end of the initialisation, the greater the chance that the log file will contain useful information.

I only really need one solution file with your code sample. NCrunch only cares about your code one solution at a time. This does mean that when you set up your custom environment variable as suggested earlier, you'll need to set it up in the NCrunch configuration for each of your solutions.

The replacing of <Reference> tags with <ProjectReference> tags is something that the new 'Infer project references' setting should handle for you automatically. I'd like to find out why this setting hasn't worked for you.
Back to top
FrankShearar
#11 Posted : Thursday, July 28, 2016 4:35:29 AM(UTC)
Rank: Member

Groups: Registered
Joined: 1/20/2015(UTC)
Posts: 17
Location: United Kingdom

Was thanked: 2 time(s) in 2 post(s)
Remco;5548 wrote:
I think that there's a couple of options for how you can work around this. Probably the simplest option would be to include references from both the production and test projects to the FSharp.Data.DesignTime assembly, then make these references 'NCrunch only'. For example:

<Reference Include="FSharp.Data.DesignTime" Condition="$(NCrunch) == '1'">
<HintPath>..\References\FSharp.Data.DesignTime</HintPath>
</Reference>

An alternative option would be to introduce a pre-build event that is executed by NCrunch for each of these projects, which copies the design-time DLL into the _ncrunchreferences directory. You can add the design-time DLL to NCrunch's 'Additional files to include' setting so that it is always in a consistent place inside the workspace where it can be copied from.

In fact, it may even be possible to just create a directory called '_ncrunchreferences' inside each of the projects, place the FSharp.Data.DesignTime.dll file inside this directory, then add this file to the 'Additional files to include' setting. In theory, the file should land inside the workspace at the right location and it should just work ... I have no easy way to test this, but it could be worth a try.


I added an _ncrunchreferences at the root of my repository (having just found this forum post because I'm trying to write a type-provider-using project for the first time), and it kind've works.

The DLLs are copied to the right place, but of course those DLLs reference other DLLs. So for instance, if your project uses FSharp.Data, you not only have to copy FSharp.Data.DesignTime.dll, you also have to add a project reference to System.Xml.Linq.

(I'm sure there are other ways of telling NCrunch how to find these transitive dependencies. I tried simply copying System.Xml.Linq (otherwise not used by my project) to _ncrunchreferences, but this did not work.)
Back to top
1 user thanked FrankShearar for this useful post.
Remco on 7/28/2016(UTC)
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.166 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download