wazzamatazz - Can you try deleting the installed package and trying again?
Sorry - have been away on holiday for the last week. Can confirm that deleting the package from LINQPad's cache and then re-adding it to the query fixed this issue. Thanks!
I think I might be running into a bug in the latest preview version. When I had a specific version of a nuget package, LINQPad references the latest version of the package and not the version specified.
It's because you're also referencing AutoMapper.Extensions.Microsoft.DependencyInjection which depends on AutoMapper >= 9.0.0.
There's a good argument for changing the precedencing logic to always honor specific version choices, although I need to think this through in more detail.
90% of our 200+ linq pad scripts are used with 3rd party sdks that are not dotnet core compatible. One of the biggest features we were looking forward to was the #load support. Is there any possibility that we will be able to get similar functionality for full framework scripts? An alternative solution that would work just as well for us would be to have a linq file specify its own extension file rather than using the extension file of the user.
We love linq pad and just purched an enterprise upgrade. I was sad to see that it didn't work for the big project we were hoping to simplify with v6.
The #load feature required significant refactoring to the LINQPad codebase, so it's impractical to port it back to LINQPad 5.
Are the SDKs that you're using planning to ship a .NET Core version? Because .NET Framework has reached the end of its life (in terms of new features), I imagine most companies will be looking to migrate to .NET Core.
As of now, I don't see anything on the products roadmaps in regards to dotnet core sadly.
On my other note above, would it be too much work to allow queries to specify their own extensions file location or have something similar to extensions in v5? The extension file has worked well for us, but swapping out extensions or portable executable locations has been a bit of a pain.
Since queries won't work without the exact extensions as someone else on the team, I believe it would feel more natural. I can move this into another topic if you would like.
Yes, unfortunately having multiple 'My Extensions' is a fair bit of work to do properly. It was one of the options that was considered as an alternative to #load.
Thank you for another fantastic update! I LOVE LINQPad and evangelize it at work and with my customers.
Quick question. Are there any extra steps required to use the new QueryCancelToken? My guess is that I should see "Has Been Canceled" and then "Cleanup" in the Results window.
I click run, then wait a moment, then click cancel. The results window stays blank, and "Query Canceled" shows up in the status bar (the image above is what I see). I can reproduce on x86 and x64 binary versions.
I've found the bug - when the debugger is active, soft cancellation is disabled.
This is now fixed in 6.0.27. It also gives better visual feedback - the icon on the cancel button now turns blue when it's detected that it can soft-cancel.
Comments
Love the changes in v6!
I think I might be running into a bug in the latest preview version. When I had a specific version of a nuget package, LINQPad references the latest version of the package and not the version specified.
There's a good argument for changing the precedencing logic to always honor specific version choices, although I need to think this through in more detail.
Joe,
90% of our 200+ linq pad scripts are used with 3rd party sdks that are not dotnet core compatible. One of the biggest features we were looking forward to was the #load support. Is there any possibility that we will be able to get similar functionality for full framework scripts? An alternative solution that would work just as well for us would be to have a linq file specify its own extension file rather than using the extension file of the user.
We love linq pad and just purched an enterprise upgrade. I was sad to see that it didn't work for the big project we were hoping to simplify with v6.
Are the SDKs that you're using planning to ship a .NET Core version? Because .NET Framework has reached the end of its life (in terms of new features), I imagine most companies will be looking to migrate to .NET Core.
As of now, I don't see anything on the products roadmaps in regards to dotnet core sadly.
On my other note above, would it be too much work to allow queries to specify their own extensions file location or have something similar to extensions in v5? The extension file has worked well for us, but swapping out extensions or portable executable locations has been a bit of a pain.
Since queries won't work without the exact extensions as someone else on the team, I believe it would feel more natural. I can move this into another topic if you would like.
thanks again!
Thank you for another fantastic update! I LOVE LINQPad and evangelize it at work and with my customers.
Quick question. Are there any extra steps required to use the new QueryCancelToken? My guess is that I should see "Has Been Canceled" and then "Cleanup" in the Results window.
This is now fixed in 6.0.27. It also gives better visual feedback - the icon on the cancel button now turns blue when it's detected that it can soft-cancel.