I'm using Prism 4 with Unity. I have a main project, and a module. The module is created as Silverlight Applications, so it builds a separate xap file.
I load the modules in the Bootstrapper's ConfigureModuleCatalog, just like the documentation states.
var moduleType = typeof (MyModule);
this.ModuleCatalog.AddModule(
new ModuleInfo
{
ModuleName = moduleType.Name,
ModuleType = moduleType.AssemblyQualifiedName,
InitializationMode = InitializationMode.WhenAvailable,
});
Everything works fine, but I notice that my main xap file also contains the dlls associated with my module. So, I set Copy Local = False on the module reference, and it builds correctly with the module dlls only in their own xap file.
But now my app won't run because I can't get the type information for MyModule. I get a FileNotFoundException.
I found that I can drop the reference entirely if I manually enter the ModuleName and ModuleType, and also set Ref = "MyModule.xap" on the ModuleInfo. This works fine, but here's the problem: I build frequently and use dynamic verion numbers. So the AssemblyQualifiedName changes too easily. Without the reference, there's no way to get it dynamically. If I drop the version number from the AssemblyQualifiedName, it doesn't work.
Surely there's some other way to get the module to load from its own xap file without it ending up also in the main xap?
Nevermind...
After researching further, it seems my mistake is in using wildcard versioning in the assembly version. It is suggested on many sites to use the wildcard in the assembly FILE version only, and use fixed version numbers on the assembly version. Then I can just drop the reference and refer to the module by its strong name with fixed version number.
I was so locked in to prism on this one. I didn't figure it out until I thought about assembly location in general. The post that solved it for me actual was about resolving sharepoint parts. Just goes to show sometimes you have to think outside the box.
Update
Looks like you can't use the wildcard in the file version... grr... I found an add-in that will work though http://autobuildversion.codeplex.com/
Anyone got a better idea?
Related
So, i'm taking over a old project that uses nmodbus (and old version at that, 2.0_1.11.0.0, we decided it was best to not update). Nmodbus uses log4net for logging messages. I need to be able to view the logged messages, but it seems like log4net doesnt like WPF, or being in not-main-project.
Adding
[assembly: log4net.Config.XmlConfigurator(ConfigFile = "log4net.config")]
To the Nmodbus project AssemplyInfo.cs file gives me this error:
Severity Code Description Project File Line Suppression State
Error Unknown build error, 'Cannot resolve dependency to assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.' OptimalProdTest
Adding log4net, with NuGet Package Manager, to the main (WPF) project causes Nmodbus to stop working. (maybe has something to do with log4net being an older version in the old nmodbus project, and adding with NuGet will download the newest? Can i somehow add log4net from the other project into the main project without NuGet?)
I found other people with similiar problem who said i should add:
FileInfo configFileInfo = new FileInfo("log4net.config");
log4net.Config.XmlConfigurator.ConfigureAndWatch(configFileInfo);
to "the entry point of your library setup your logger", one guy said, another said "in the constructor of the wrapper class". However, i do not know what files these guys are talking about, nor do i know which project they meant (add to main project or nmodbus?).
( https://social.msdn.microsoft.com/Forums/vstudio/en-US/0c5d7fbb-94a3-4221-ab91-9732c5acee58/cannot-resolve-dependency-to-assembly-because-it-has-not-been-preloaded )
I'm lost and i can't find much help when googling. Anyone has any idea what i should do to be able to view the logs from log4net in nmodbus?
To migrate an application I want to continue using the plain old settings that still come along with .Net5 (App.Config, Settings.settings and so on).
I need a simple built in solution without additional dependencies.
The proposed way seems to be appsettings.json or similar.
For that to use with WPF you need to add some additonal dependencies which bloat the project when
publishing it as single exe (not self contained). It is over-the-top for simple applications.
I followed the steps here:
Equivalent to UserSettings / ApplicationSettings in WPF dotnet core
The accepted answer from Alexander works for a normal exe built.
These are the generated files
MyApp.dll
MyApp.dll.config
MyApp.exe
Modifying "MyApp.dll.config" with an editor directly reflects the changed data in the code.
MessageBox.Show(Settings.Default.SomeConfigValue);
The used config file can be displayed using
var config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
MessageBox.Show(config.FilePath);
It displays
C:\Projekte\MyApp\MyApp\bin\Debug\net5.0-windows\MyApp.dll.config
Unfortunately this fails for single exe
These are the generated files (in publish folder)
MyApp.dll.config
MyApp.exe
Modifying "MyApp.dll.config" or "MyApp.exe.config" has no effect. The file does not seem to be used by the framework.
Above messagebox now shows
C:\Projekte\MyApp\Publish<Unknown>.config
How to get the built-in configuration system work with single exe?
I have a trayicon in my WPF App. When I was debugging in Visual Studio, it works well:
System.Windows.Forms.NotifyIcon ni = new System.Windows.Forms.NotifyIcon();
ni.Icon = new Icon("../../logo,ico");
But after I published it, the App threw an exception saying it could find the path of the image of the trayicon. I've search a lot resources on online, I saw many solutions use pack, but it seems pack only accept Uri variable and the path for trayicon must be string. I also tried to create a folder called Resource under the project solution and put the image file into it. This was the same: worked while debugging but would not work after publishing..
So based on #WPF Germany's suggestion, I solved the path issue after publishing the App by Clickonce. However, if I copy a App shortcut to system startup folder, it would find the ico in C:\WINDOWS\system32, which is not easy to workaround since systems32 usually requires admin right to access. Any idea for that?
Did you check, that your logo.ico file is copied to output path?
In VS you have multiple options to provide your Resource files.
First option:
Select your logo.ico file in solution explorer and choose None as Build Action and Copy always at Copy to Output Directory (at file properties).
After compiling you will find the file in a subdirectory of our OutputPath.
use (if logo.ico is placed in your projects root):
ni.Icon = new Icon("logo.ico");
other option:
Use Resource as Build Action and build your Icon using a Stream created from Resources.logo...
I am currently faced with a dilemma in regards to adding any kind of DLL to a ColdFusion project. I have done a ton of research but nothing seems to be simplistic enough to grasp an understanding. I have a Winform that uses the same DLL in the Reference which makes life easy. When looking to add the same DLLs to a ColdFusion project, it doesn't seem to be working. I have tried using the following:
<cfobject type="com" name="myObj" assembly="C:\DocViewer\AxInterop.SHDocVw.dll">
Here is the error message I am receiving as well:
Attribute validation error for tag CFOBJECT. It has an invalid
attribute combination: assembly,name,type.
This site has been very helpful in the past and I am hoping to learn how this DLL in CF9 works so that I do not have to completely rewrite an entire program when the current one works perfectly.
From comments
I tried adding the DLL using the regsvr32 but here is my error now:
the module was loaded but the entry-point dllregisterserver was not found
Well it looks to me like you're using the cfobject attributes for a .NET object instead of for a COM object. The cfobject tag is one of those tags where the attributes vary by action/type, like cfcontent, cffile and cfdirectory (and a bunch of others that don't immediately spring to mind).
So you need the documentation for accessing COM objects specifically, which for the latest version of Adobe's CFML engine is located here: https://wikidocs.adobe.com/wiki/display/coldfusionen/cfobject%3A+COM+object
There's a typo on the docs page, but it looks like this should work for you (although I'll admit it's been a while since I've invoked a COM object):
<cfobject
type = "com"
class = "path.to.com.Class"
name = "myObj"
action = "create|connect">
It looks like you would use action="connect" if you have it installed as a Windows Service, or create if you want CF to instantiate the DLL, but I would guess having it installed as a service would be easier. I'm just guessing, but I think "path.to.com.Class" would be the name of the service if you're using it that way, or it would be the logical path to the .dll file if the CF server is instantiating it. If neither of those options work, then there might either be a version incompatibility if this is being moved to a newer OS, or the service might be misconfigured.
The error message from registering the DLL sounds like (and I'm guessing because I've never created a windows service DLL) it's looking for a specific class or function in the DLL in order to register it as a service in Windows and it can't find that "entry point" in the DLL (i.e. in the same way that Java will look for a "public static void Main(String args)" as the entry-point to a Java program). That may be necessary for a Service, but it's probably not necessary for a generic DLL that might be accessed and used in some other way, so it's possible this DLL might work, but not be compatible with Service registration.
So going back to your sample code, this might work:
<cfobject type="com" name="myObj" action="create"
class="C:\DocViewer\AxInterop.SHDocVw.dll">
I'm attempting to use Dotfuscator 4.7.1000 to obfuscate a Silverlight library that is strongly named. When I attempt to do so, I get the following error message:
External type not found
System.Data.Services.Client.LoadCompletedEventArgs,System.Data.Services.Client,
Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
I have tried adding this assembly to the GAC, and have tried adding user defined assembly load paths to the configuration to locations where this assembly is located to no avail.
I then tried adding System.Data.Services.Client to the input assemblies and ran it again. This time it gets further, but ultimately I get:
Warning: Password protected Strong Name files are not supported
sn returned 1.
It appears as though it is attempting to run sn.exe on System.Data.Services.Client.dll with my local key. I've tried excluding this assembly from any obfuscation tasks, but it continues to do so.
Is there something I'm missing when trying to obfuscate this library? Is there some other way to directly point it to the DLL it can't seem to find that I don't know about? Or can I include the DLL in the project without it trying to obfuscate the Silverlight library?
And for the moment, please no suggestions on alternate obfuscators. My company has a license for Dotfuscator and I'd like to get this running using that. Thanks!
Somehow I must have been screwing up my user defined assembly load paths. As soon as I re-added the path to the Silverlight 4.0 client DLLs everything worked without having to reference System.Data.Services.Client.