Added dialog box for paket trace info #38
Conversation
|
Awesome work. Keep it coming. |
Added dialog box for paket trace info
|
You guys rock! When will this be in the extensions gallery? |
|
@vasily-kirichenko @dungpa could you please describe your release strategy with the F# PowerTools? Is there a way to automate the upload to the gallery? |
|
I <3 u all =] |
|
Regarding automating gallery upload. Short answer: not possible. I did hear of someone who managed to "automate" the upload process with Selenium. But since the VSIX gallery can only hold one version at a time (unlike NuGet), it might as well be a manual process... Shameless plug(in): I wrote a plugin for TeamCity that allows hosting private VS galleries in TC :) https://github.com/hmemcpy/teamcity-vsix-gallery/ |
|
Is it at least possible for a group of people to own the plugin together? Or is it tied to one account? |
|
It's tied to one live account, I believe, yes :( On Mon, May 18, 2015 at 9:15 AM, Steffen Forkmann [email protected]
|
|
mhm. it works on my laptop, but on my PC I get this happens when I type "xunit" into the search form and after the throttle. |
|
so the automatic deploy is solved:
the missing method issue remains |
|
Nice! Does it work in English? :) On Mon, May 18, 2015 at 12:46 PM, Steffen Forkmann <[email protected]
|
|
Yep it does.
|
|
awesome |
|
I absolutely love it |
|
@forki hey hey! which method is missing, is it part of system.reactive? are you building with .net 4.5? |
|
Yep .NET 4.5 and please see #38 (comment) |
|
@forki Yup, it's the Xamarin extension fucking you up. Microsoft is shipping two separate builds of system.reactive, one for .NET 4.0 and another for .NET 4.5. Both with the same signing key snd version. As a result, the runtime doesn't distinguish them (runtime version is not a part of the assembly identification) and will only load one of them, whichever comes first. If the first is the one for .net 4.0, any 4.5 methods will not be a part of it. Result: MethodNotFoundException The only way to fix this is to either load your extension before they do (if you can, it's a race), or ship your own copy of system.reactive with a different signing key so it can be loaded side-by-side with the one Xamarin is loading, which is what I'm doing. I have a fork at https://github.com/shana with a different key, you can also use the ones that ship with the GitHub Extension for VS2015 |
|
WTF!? I really appreciate your help. Is there a chance to reference this via github? Or should we copy the files locally and commit. |
|
or should we ilmerge the whole mess? |
|
@forki What I did was create nuget packages with the built dlls, and add those to my repo and direct nuget to pick up packages from it, so there's no need to change the build system itself. I can push those to the releases page in the repo if you want to reuse them. |
|
yes please, please. |
|
They're the exact same thing that everything is built with (and exactly the same thing that's in the nuget packages that reactiveui uses), only with a different signing key so that the runtime doesn't use an incompatible one by mistake when deciding which dependencies to load. I'm currently away from my computer, will be back to it in a couple of hours and I'll upload then. Microsoft needs to start versioning or signing the two builds differently so this doesn't happen. We probably need to make some noise over at their repo, they probably don't even realize how badly they're screwing this up. |
|
@shana if you publish the nuget on your site, then I can download and use paket to replace them with the original versions. This would be a very good work around for us. Thanks so much. |
|
Welcome to DLL hell. There was a very good reason why all the corlib and class libraries were versioned differently for every runtime they target, even if they might be technically almost the same. Someone forgot that detail somewhere along the way. |
|
To be fair, this only happens in environments where you have no control over which dlls are loaded. A normal app wouldn't hit this because even if it allowed external plugins, its main dependencies would have already been loaded first (and if it used .net 4.0 reactive, well, all the plugins would have to stick to that, too). It's the scenario where plugins are racing to load dependencies that are not a part of the main app that things get crappy. |
|
I've created a new release on my fork with the relevant nuget packages: https://github.com/shana/Rx.NET/releases/tag/v2.2.5-custom |
|
Thx for helping so fast. as expected now I have issues with the ReactiveUI #40 - I assume it's unhappy about the changed strong naming. |
|
@forki Oh, darn, I'm sorry, I keep forgetting I ended up building my own build of reactivevui (and all my other dependencies) so I could strong name everything, so for me it was just a question of changing the references. 😕 An alternative is to revert my key change and change the version of the assemblies instead, to be sure that you get the one you want and not whatever is loaded at that point. I added the nuspec files to the repo so it's easy to package things just by doing nuget pack for each nuspec after doing a build. Xamarin says they're going to change the version of the reactive dlls they ship in VS 2015 to 4.5 - https://twitter.com/kzu/status/600333293578498048. Of course, someone else might come in before them and load the wrong dlls and break you again, it's a toss up sigh |
|
I recommend you ILMerge the world and be done with it tbqh |
That's probably the best for your use case. I wish I could do this too, but we have strict footprint requirements that require us to lazy-load as much as possible... sigh |
|
ILMerged version (see #41) seems to work. |
|
@forki Yay 😄 Apologies for the waste of time trying the nuget packages, I keep forgetting about the little detail of having custom builds of everything 😛 |
This PR is to start #37
Not pretty as atom, but a start.