I have an assembly that if I run ngen on this, it never finishes. Never, as in "I left it over night, and it still ran".
Is it possible to get wyUpdate to not run ngen on the assemblies?
I guess I can go download the source for it and build it myself, I'm just wondering if there's an option somewhere I can enable or disable that already handles this.
No, not without modifying the wyUpdate source code to filter out the particular executable that you don't want ngened.
Can I ask you why NGEN causes your program to never close? Have you investigated it?
The reason I ask is this sounds like a bug in NGEN. And if it is Microsoft should be notified, rather than implementing a workaround in wyUpdate.
Any chance I can see your source code, or at the very least the executable that's acting up? (If so, send them to wyatt@wyday.com )
Hi.
The entire class library is available here:
http://svn.vkarlsen.no:81/svn/LVK/LVK_3_5/trunk
This is for Visual Studio 2008, and the problematic class library is the LVK.Core project.
So to reproduce:
1. Download the source through subversion2. Build the LVK.sln file (or at least right-click on LVK.Core and choose rebuild), build for x863. Try to ngen LVK.Core.dll
I'll post a question on Stack Overflow about it, perhaps there's something I've done wrong with the class library configuration.
Question posted:
Let's say I build my own copy of wyUpdate and disables the call to NGEN, what happens if you release an update to wyUpdate, will wyUpdate attempt to update itself, and fail?
I don't know how common this problem is, I suspect it is not very common, but perhaps a fix that you could incorporate would be that for me to add a second file to the update process, named exactly like the assembly, just with an additional ".no_ngen" extension. When you find this file during the optimization process, you remove this file (ie. the .no_ngen file), and don't run ngen on the assembly.
This would not introduce changes to other existing users of wyUpdate, but would allow me (and others, if the ngen-process is for any reason not wanted) to disable ngen for specific assemblies.
An addition like this to NGenInstall:
string noNgenFilename = string.Format("{0}.no_ngen", filename);if (File.Exists(noNgenFilename)){ File.Delete(noNgenFilename); return;}
Of course, this does no error checking in regards to the file not being deletable for any reason.
Anyway, I'll experiment a bit, I'm going to create a new class library project, and start copying over files to see if there is a definite point where it starts hanging.
I haven't looked at your code yet, but are you running NGEN on the .dll file or the .exe that uses the .dll? Or both. And does it hang on both, or just one?
The reason I ask this, is because wyUpdate only NGEN's the .exe files. It lets NGEN handle the dependencies.
Ok, in my manual test, I try it on the dll.
But in the test project, there is an executable that uses the dll, and the optimization step of wyUpdate just hangs, and I can verify that NGEN is running. Killing NGEN makes wyUpdate complete successfully.
This also explains why my naive "fix" did not remove the .no_ngen file 🙂 I need to make it for the .exe file instead.
But hmm... The naive "fix" seemed to speed up the update. This makes no sense.
I do know that NGEN on LVK.Core.dll hangs, but the update now completed in a fairly short time, even though, as you say, it should not matter since you NGEN the executable.
I'll dig some more.
On the upshot, it seems NGEN for .NET 4.0 is able to complete. It took a while, but it did complete.
Ok, in my manual test, I try it on the dll.
But in the test project, there is an executable that uses the dll, and the optimization step of wyUpdate just hangs, and I can verify that NGEN is running. Killing NGEN makes wyUpdate complete successfully.
This also explains why my naive "fix" did not remove the .no_ngen file 🙂 I need to make it for the .exe file instead.
But hmm... The naive "fix" seemed to speed up the update. This makes no sense.
I do know that NGEN on LVK.Core.dll hangs, but the update now completed in a fairly short time, even though, as you say, it should not matter since you NGEN the executable.
I'll dig some more.
On the upshot, it seems NGEN for .NET 4.0 is able to complete. It took a while, but it did complete.
We'll be adding .NET 4.0 support to wyUpdate a little later this month (NGENing .NET 4.0 files, GAC installation, etc.). As far as this bug goes, I'm going to have to investigate a little deeper.
And to answer you earlier question, to avoid wyUpdate automatically updating itself with a newer version of our code rather than your code you'll need to maintain your own copy of wyUpdate updates. Then in your wyBuild project click File->Properties->wyUpdate and change "http://wyday.com/files/wyupdate/updates/client.wys" to "http://yoursite.com/whatever/server.wys".
Ok, I'll dig a bit, thanks for pointing me to File->Properties, didn't notice that one.
It was my generic tuple code that created the problem.
I had generated generic tuples up to arity of 20 (ie. Tuple<T1, T2, T3, ..., T20>) just for the sake of it, using a python script.
I reduced the max arity to 6, recreated the base classes and removed 7-20, and now it compiles with NGEN in a fraction of a second, as expected.
I'll update my Microsoft Connect post about the problem, but as far as wyBuild/wyUpdate goes, there's nothing to be done.
Great, I'm glad to see that you found the solution.
