Is there a way to persist CS-Script internal assembly cache between subsequent application's runs?
Used component: http://www.csscript.net/
The desired behavior is:
when I compile an assembly form a script string and I close the application, the next time I run the application the compiled assembly with matching script string is found and no recompilation is needed.
This question is follow-up of another question:
Is there a way to call C# script files with better performance results?
Here is my code, but every script string requires recompilation with every restart of parent .NET application.
public interface ICalculateScript
{
Exception Calculate(QSift qsift, QSExamParams exam);
}
...
void Calculate(string script)
{
CSScript.CacheEnabled = true;
//Can following command use built-in cache to load assembly, compiled by this line of code, but by another instance of this app which run in the past and has been meanwhile closed?
Assembly assembly = = CSScript.LoadCode(script, null);
AsmHelper asmHelper = new AsmHelper(assembly);
ICalculateScript calcScript = (ICalculateScript)asmHelper.CreateObject("Script");
calcScript.Calculate(this, exam);
}
Related problem:
The folder of temp scripts created by Cache in CS Script C:\Users\vdohnal\AppData\Local\Temp\CSSCRIPT\Cache\2015108000 has 41 MB and growing with files few months old.
In the output window of WPF App there are first chance exceptions:
A first chance exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll
A first chance exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll
A first chance exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll
A first chance exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll
A first chance exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll
'ESClient.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Users\vdohnal\AppData\Local\Temp\CSSCRIPT\Cache\2015108000\af621e10-d711-40d7-9b77-0a8e7de28831.tmp.compiled'
C:\Users\vdohnal\AppData\Local\Temp\CSSCRIPT\Cache\2015108000
I got an answer fom Oleg Shilo which pointed me in the right direction:
The cache folder indeed grows as new scripts are compiled/loaded. This
is the nature of the caching. It seems that it "grows without control"
though it is not. Once cache is created for a given script file it is
never duplicated and the new cache update is always written over the
existing one.
The problem in your case is that every time you load the file you give
it a unique name thus you are creating a new unique cache. To fix it
you need to start using the same name for the script file every time
you load/execute it.
Alternatively you can completely take over the caching location and
specify what ever cache name you want. It is that second parameter
that you pass null for:
Assembly assembly = CSScript.LoadCode(script, null);
I used following code:
if (assemblyFileName == null)
assembly = CSScript.LoadCode(script, null); //In case there is no name specified - when my custom temp folder cannot be created etc.
else
assembly = CSScript.LoadCode(script, assemblyFileName, false, null); //Specify full path and file name with extension
Thanks to this I have complete control over cached assembly name and location.
If cached assembly with appropriate script already exists, I can simply load it instead of compiling a new one:
Assembly assembly = Assembly.LoadFrom(assemblyFileName);
AsmHelper asmHelper = new AsmHelper(assembly)
The speed of initial loading is better and there is no uncontrollably growing cache.
Related
During testing of a command line based program I delibrately removed a DLL from the execution directory. This of course caused the Could not load file or assembly exception to trigger when the program started, and dumped the raw exception details onto the command line:
Unhandled Exception: System.IO.FileNotFoundException: Could not load
file or assembly 'MyDLL, Version=1.2.3.14056, Culture
=neutral, PublicKeyToken=0a0932194e205074' or one of its dependencies. The system cannot find the file specified. at
MyApp.Program.Program.Main(String[] args)
I don't want the user to see these raw details, but I can't see how/where to catch this exception in order to sanitize the presented message.
So what is the best/accepted way to catch something like this?
You can register to the Unhandled Exception handler and treat it like so:
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler((x, y) =>
{
var exception = y.ExceptionObject as Exception;
if (exception is System.IO.FileNotFoundException)
Console.WriteLine("Please make sure the DLL is in the same folder.");
});
Make sure this event registration is executed before any reference to MyDLL in your code. A static constructor in Program.cs might be a good option.
I am using ILMerge and Quartz.NET in a C# .NET 4.0 Windows Service application. The app runs fine without using ILMerge, but now that we're nearing shipping release, I wanted to combine all DLLs into a single executable.
Problem is, that ILMerge seems to work fine, but when I run the combined executable, it throws this exception:
Unhandled Exception: Quartz.SchedulerException: ThreadPool type 'Quartz.Simpl.SimpleThreadPool' could not be instantiated. ---> System.InvalidCastException: Unable to cast object of type 'Quartz.Simpl.SimpleThreadPool' to type 'Quartz.Spi.IThreadPool'.
at Quartz.Util.ObjectUtils.InstantiateType[T](Type type) in :line 0
at Quartz.Impl.StdSchedulerFactory.Instantiate() in :line 0
--- End of inner exception stack trace ---
at Quartz.Impl.StdSchedulerFactory.Instantiate() in :line 0
at Quartz.Impl.StdSchedulerFactory.GetScheduler() in :line 0
Does anyone have any idea why this is? I have been wasting over 4 hours already and I can't figure it out. If I don't combine with ILMerge, then everything runs fine (with the Quartz.dll and Common.Logging.dll in the same directory).
I'm sure someone must have tried packaging Quartz.net up like this before, any ideas?
Disclaimer: I don't know Quartz.NET at all, although I spent some time struggling with ILMerge. When I finally understood its limitations... I stopped using it.
ILMerge'd application tends to have problems with everything which contains the word "reflection".
I can guess (I've never used Quartz.NET) that some classes are resolved using reflection and driven by configuration files.
Class is not only identified by its name (with namespace) but also by assembly it is coming from (unfortunatelly it doesn't get displayed in exception message).
So, let's assume you had (before ILMerging) two assemblies A (for you Application) and Q (for Quartz.NET).
Assembly 'A' was referencing assembly 'Q' and was using a class 'Q:QClass' which was implementing 'Q:QIntf'.
After merging, those classes became 'A:QClass' and 'A:QIntf' (they were moved from assembly Q to A) and all the references in code has been replaced to use those (completely) new classes/interfaces, so "A:QClass" is implementing "A:QIntf" now.
But, it did not change any config files/embedded strings which may still reference "Q:QClass".
So when application is reading those not-updated config files it still loads "Q:QClass" (why it CAN find it is a different question, maybe you left assembly 'Q' in current folder or maybe it is in GAC - see 1).
Anyway, "Q:QClass" DOES NOT implement "A:QIntf", it still implements "Q:QIntf" even if they are binary identical - so you can't cast 'Q:QClass' to 'A:QIntf'.
The not-ideal-but-working solution is to "embed" assemblies instead of "merging" them. I wrote a open-source tool which does it (embedding instead of merging) but it is not related to this question. So if you decide to embed just ask me.
You can test it by removing (hiding, whatever works for you) every single instance of Q.dll on your PC. If I'm right, the exception should say now 'FileNotFound'.
You could try creating your own ISchedulerFactory and avoid using reflection to load all of your types.
The StdSchedulerFactory uses this code to creat a threadpool. It's where your error is happening and would be the place to start looking at making changes:
Type tpType = loadHelper.LoadType(cfg.GetStringProperty(PropertyThreadPoolType)) ?? typeof(SimpleThreadPool);
try
{
tp = ObjectUtils.InstantiateType<IThreadPool>(tpType);
}
catch (Exception e)
{
initException = new SchedulerException("ThreadPool type '{0}' could not be instantiated.".FormatInvariant(tpType), e);
throw initException;
}
The ObjectUtils.InstantiateType method that is called is this one, and the last line is the one throwing your exception:
public static T InstantiateType<T>(Type type)
{
if (type == null)
{
throw new ArgumentNullException("type", "Cannot instantiate null");
}
ConstructorInfo ci = type.GetConstructor(Type.EmptyTypes);
if (ci == null)
{
throw new ArgumentException("Cannot instantiate type which has no empty constructor", type.Name);
}
return (T) ci.Invoke(new object[0]);
}
Right after this section in the factory, datasources are loaded using the same pattern and then the jobs themselves are also loaded dynamically which means you'd also have to write your own JobFactory. Since Quartz.Net loads a bunch of bits and pieces dynamically at runtime going down this road means you might end up rewriting a fair amount of things.
The file is present, correctly named and not corrupted. If I move it out and back in from the "Bin", it works again, for about 5 minutes, then the error bellow comes back. Any operation that refreshes the file is fine, publishing it the anew, renaming or moving makes the site work again, for a moment.
{"Message":"Could not load file or assembly \u0027Ouranos,
Version=1.0.0.0, Culture=fr-CA, PublicKeyToken=null\u0027 or one of
its dependencies. Le fichier spécifié est introuvable.","StackTrace":"
at Services.Asynchrone(String DimensionX, String DimensionY, String
Action, String Culture, String Utilisateur, String Interface, String
Source, String Champ, String Valeur, String Classement, String
Direction, StriFileNotFoundExceptionng Page, String
Itérations)","ExceptionType":"System.IO."}
Fusion did give me an error code (0x80070002), which pointed me to get Process Monitor. Which lead me to the temporary assembly folder. Now I may be wrong about this. Comparing the cache files from an healthy website and the sick one, I noticed something odd.
Healthy website as all the DLL from the BIN in cache.
The sick website is missing two DLL in the cache that are present in the BIN.
Now, I know that ASP.net tends to say that the main library is missing when it's in fact one of the referenced library that is missing. In this current situation I don't know what I could do to fix that problem. The two DLL are not set in the cache, thus when it tries to load the main DLL it fails locating the two others from the cache and throws a file not found on the main DLL.
The two culprits are:
PresentationCore.dll
WindowsBase.dll
To troubleshot this kinf of errors, you can use Fusion log, instructions about how to enable it and how to use it can be found here: How to enable assembly bind failure logging (Fusion) in .NET.
It would seem that the following code actually fixes the problem. It checks for all the required assemblies for the assembly and loads the missing. I had such a code before and it did not work, because without the !(Assemblée is System.Reflection.Emit.AssemblyBuilder) && (Assemblée.GetType().FullName != "System.Reflection.Emit.InternalAssemblyBuilder") was not present and has the code causing an exception in .net 4.0 and over. It's not elegant, but it does the job.
public static void Chargeur()
{
var Assemblées_Chargées = (from Assembly Assemblée in AppDomain.CurrentDomain.GetAssemblies() where !(Assemblée is System.Reflection.Emit.AssemblyBuilder) && (Assemblée.GetType().FullName != "System.Reflection.Emit.InternalAssemblyBuilder") && (!Assemblée.GlobalAssemblyCache) && (Assemblée.CodeBase != Assembly.GetExecutingAssembly().CodeBase) select Assemblée).ToList();
var Chemins_Chargés = Assemblées_Chargées.Select(Assemblée => Assemblée.Location).ToArray();
var Chemins_Référencés = Directory.GetFiles(AppDomain.CurrentDomain.BaseDirectory, "*.dll");
var Assemblées_NonChargées = Chemins_Référencés.Where(Références => !Chemins_Chargés.Contains(Références, StringComparer.InvariantCultureIgnoreCase)).ToList();
Assemblées_NonChargées.ForEach(path => Assemblées_Chargées.Add(AppDomain.CurrentDomain.Load(AssemblyName.GetAssemblyName(path))));
}
I am trying to add an image to a button (C# Winform, VS2010). I have added the resource by Adding Existing Item in the Resources.resx file. I then assign my image to the button and all appears well. When i run my program i get:
An unhandled exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll
Additional information: Could not load file or assembly 'BmsReplayAnalysis.resources, Version=1.0.0.0, Culture=en-US, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
in this code:
public static System.Drawing.Bitmap play1 {
get {
object obj = ResourceManager.GetObject("play1", resourceCulture); <-- DIES HERE
return ((System.Drawing.Bitmap)(obj));
}
}
Can anyone tell me what i am doing wrong?
When you just give it a name of a file, when you run it, it looks for it in the folder that it is running out of. If you are running in debug mode, it will look for play1 inside the debug folder. if its not there its an error.
I have an AppDomain that I'm using to load modules into a sandbox with:
class PluginLoader
{
public static AppDomain PluginSandbox;
static PluginLoader()
{
AppDomainSetup ads = new AppDomainSetup();
ads.ApplicationName = "Plugin Modules";
PermissionSet trustedLoadFromRemoteSourceGrantSet =
new PermissionSet(PermissionState.Unrestricted);
PluginSandbox =
AppDomain.CreateDomain("Plugin App Domain",
null, ads, trustedLoadFromRemoteSourceGrantSet);
}
And then later on, I'll pull in the DLL I need and create an object instance:
public IPlugin FindPlugin(string pluginName)
{
ObjectHandle handle =
PluginSandbox.CreateInstance(pluginName,
"Plugins." + pluginName);
IPlugin ip = (IPlugin)handle.Unwrap();
return ip;
}
I run through this a couple of times with no problems. Getting instances of various objects out in the Sandbox, with no problems.
A bit later in the code, in another method, I need to find the assembly to get an embedded resource (a compiled in data file, with ManifestResource). So I call:
Assembly [] ar = PluginSandbox.GetAssemblies();
And the error gets thrown:
A first chance exception of type 'System.IO.FileNotFoundException'
occurred in PluginRunner.dll.
Additional information: Could not load file or assembly '10wl4qso,
Version=1.0.3826.25439, culture info=neutral, PublicKeyToken=null'
or one of its dependencies. The system cannot find the file specified.
I'm not surprised. '10wl4qso' isn't the name of the assembly, the dll, or anything like it. In fact it seems pseudo-random for each run. Plus the added fun of GetAssemblies isn't even documented to throw this exception.
Now I can call GetAssemblies right after I get the initial object just fine, and everything is peachy. But a couple of seconds later, in a different method I get this. Being remoted, PluginSandbox has no useful information at all in the debugger.
I'm catching UnhandledException and DomainUnload on the AppDomain and neither is being triggered.
Why does my AppDomain suddenly not know about its assemblies?
Where's that garbage data coming from?
What can I do to prevent either/both of these from happening?
This weird named assembly you're seeing is probably generated by XmlSerializer. The XML serializer will output a dynamic assembly to be able to quickly serialize and deserialize a specific type quickly. Check your code for uses of XmlSerializer, comment them out and see if the problem occurs again.
I don't know if it helps you...
Try to override InitializeLifeTimeService on IPlugin. Your IPlugin implementation should inherits from MarshalByRefObject first.
public class PluginSample : MarshalByRefObject, IPlugin
{
public overrides object InitializeLifetimeService()
{
return null; //Return null to infinite object remote life.
}
//...implementation
}
Take a look at this article:
RemotingException when raising events across AppDomains