We've a project that has TypeConverters. Every time we load the project, it pops up a dialog asking to find the assemblies that they are in. When using the designer interactively, this is simply a mild annoyance, however, we'd like to use the CliGenerator non-interactively. Is there any way to specify where to look for the assemblies to prevent the dialog from popping up and halting the script?

From the documentation

LLBLGen Pro at startup probes any assembly in the TypeConverters folder in the LLBLGen Pro installation folder for types derived from System.ComponentModel.TypeConverter. All these types are seen as type converters and stored in the designer internals and are enlisted in the entity editor and typed view editor when a field is selected. Type conversion definitions

Matt

Thank you. Sorry I didn't RTFM first-- I did look, just not hard/long enough. Unfortunately, this does not solve our problem, although it may make life a little more convenient. We have a build server which can possibly be running multiple builds of the same solution (just with different branches). They would need different versions of the same assembly to be in the TypeConverters folder, but this is impossible for obvious reasons. We've tried setting the project's AdditionalTypeConverterFolder property but this seems to have no effect. Any ideas?

OK, I tried using a .assemblylocations file. Though cumbersome, it does work when I'm opening the designer (handy). However, it doesn't work with the CliGenerator; in fact it barfs with the following:

LLBLGen Pro Command line code generator v2.6.0.0.06052008 (c)2002-2008 Solutions Design. http://www.llblgen.com Generates code for LLBLGen Pro projects on the command line.

Exception caught.

Message: Could not load file or assembly 'Opw.Common, Version=1.3.0.0, Culture=neutral, PublicKeyToken=a1ac645d4f12a833' or one of its dependencies. The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG)) Source: mscorlib Stack trace: at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.Load(String assemblyString) at System.UnitySerializationHolder.GetRealObject(StreamingContext context) at System.Runtime.Serialization.ObjectManager.ResolveObjectReference(ObjectHolder holder) at System.Runtime.Serialization.ObjectManager.DoFixups() at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) at SD.LLBLGen.Pro.ApplicationCore.Project.Load(String projectPathFileName) at SD.LLBLGen.Pro.Tools.CommandLineGenerator.Startup.StartProcess(String projectFile, String rootNamespace, String languageName, String platformName, StringtemplateGroupName, String presetName, String destinationFolder, Boolean clearDestinationFolder, Boolean loadValuesFromProjectFile) Inner exception:-----------------------

Exception caught.

Message: Absolute path information is required. Source: mscorlib Stack trace: at System.Security.Util.StringExpressionSet.CreateListFromExpressions(String[] str, Boolean needFullPath) at System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess access, AccessControlActions control, String[] pathListOrig, Boolean check ForDuplicates, Boolean needFullPath, Boolean copyPathList) at System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess access, String path) at System.Reflection.Assembly.LoadFile(String path) at SD.LLBLGen.Pro.ApplicationCore.Project.OnProjectLoadAssemblyResolveFailure(Object sender, ResolveEventArgs args) at System.AppDomain.OnAssemblyResolveEvent(String assemblyFullName)

Inner exception: <null>

Application log:

Based on the message, I tried switching to absolute paths, which works, but again is unacceptable.

Why don't you place the typeconverter assembly in the TypeConverters folder? Or if that's not possible, in the folder specified in the project properties (AdditionalTypeConverterFolder) ? (which can be relative to the lgp file)

If you did do this, it might be something else.

The AdditionalTypeConverterFolder doesn't work, in the designer or the CliGenerator. I would be delighted if it did. This is in 2.6 Final (October 6th, 2008 ).

Jeff wrote:

The AdditionalTypeConverterFolder doesn't work, in the designer or the CliGenerator. I would be delighted if it did. This is in 2.6 Final (October 6th, 2008 ).

'Does not work' is not something I can work with, sorry.

What exactly did you specify as additional folder, and what did happen: error, nothing happened, WHEN did it not work etc.

Keep in mind that the project file is deserialized using the binary formatter. So if you have a custom type which is returned by your typeconverter, the type converter dll has to be loadable by .NET fusion (the CLR assembly loader), as it has to resolve the .net type.

Type converters themselves are mapped into the definitions post-load so for type converters alone, the folder does work. However, in the case of the custom type (e.g an enum) this doesn't work, as the CLR looks in the application local folder, the folders specified in the probing path in the config file and in the GAC.

So I think what you're seeing is that you have a custom type AND a type converter in the same dll and you get the pop up because of the type, not because of the typeconverter.

As pop ups etc. are annoying, you can also fix it with an assembly load file which is a file which let you specify the location of the assemblies to load. This solves you from the popups.

Otis wrote:

So I think what you're seeing is that you have a custom type AND a type converter in the same dll and you get the pop up because of the type, not because of the typeconverter.

This is exactly what is happening. We are converting bytes to enums which are defined in the same assembly. I see now where this is mentioned in the docs, but I initially dismissed it because it also says that it will throw an exception, which is not the behavior that it exhibits.

Otis wrote:

As pop ups etc. are annoying, you can also fix it with an assembly load file which is a file which let you specify the location of the assemblies to load. This solves you from the popups.

Ok. This is acceptable. It turns out that the CliGenerator doesn't work if the you specify both the project path on the command line and the assembly paths in the assembly load file using relative paths. If one or the other is absolute it's ok. So there's a very simple workaround in our instance: using CliGenerator %CD%\project.lgp ... instead of CliGenerator .\project.lgp. So now I have generation scripted out in a way that could be run unattended from multiple codelines of the same project at once, so we might be able to integrate this in to our build. Excellent! Thanks for your help. Sorry if some of my questions were less than helpful.