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?
Related
I'm trying to create setup for my project. I added the new project with "Setup . When I add primary output to the project, I got the following warning.
"The following files may have dependencies that cannot be determined automatically. Please confirm that all dependencies have been added to the project C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\Ltocxu.ocx C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\LtocxVariantu.dll
Please guide me to solve this problem.
Thanks in advance..
This warning is a "general" warning and not one that may necessarily stop the software from working. It only means that since OCX and DLL files are older technology, the new setup project may not be able to detect the dependencies for these files. You may want to check the LeadTools documentation or find the dependencies manually and add them to the distribution as required.
Again, since this is a general warning for the tool (setup project) itself and not your project specifically, even if you add any missing dependencies.
In this particular case, the warning might be valid. The old LEAD Main OCX (Ltocxu.ocx) did require additional DLLs to work. Some of them are directly linked as dependencies like the kernel and display DLLs (LtKrnu.dll and Ltdisu.dll).
Others are dynamically loaded if needed, such as file format DLLs.
You should be able to find full details in the topic "Files to be Included with Your Application" in LEADTOOLS help files for your specific version of the toolkit.
At out company, we use NuGet to version our internal libraries. Every commit to a library triggers the build server, which churns out a new NuGet package and uploads it to our internal feed.
This works pretty well for us, but we often run into an issue with the WinForms designer, where it would refuse to load a form with an error message like this:
Die Datei oder Assembly "UILib, Version=1.0.0.906, Culture=neutral, PublicKeyToken=null" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
(Roughly: The file or Assembly "UILib, Version=1.0.0.906, Culture=neutral, PublicKeyToken=null" or one of its dependencies could not be found. The system cannot find this file.)
This is only a designer issue though - the application will build without a problem and will run as intended.
This is the problem, but now you need some valuable context to make any sense out of it. The form that I'm trying to open is part of an application (let's just call it App), and it contains a UserControl which is part of our product-specific UI library (ProductUILib). That library in turn references our general-purpose UI library (UILib). However, the application itself also depends on UILib directly.
Both UILib and ProductUILib are provided through their own NuGet packages. So, the simplified dependency graph is like this:
App ----> ProductUILib ----> UILib
| ^
------------------------------|
All is well as long as ProductUILib and App reference the same version of UILib (say, 1.0.0.906). However, if I modify UILib and then update my NuGet dependencies in App, App will get and reference the latest version of UILib (say, 1.0.0.932). ProductUILib was built against the older UILib, but that should be fine because all changes to UILib are backwards compatible, and we don't have strong names for those libraries either. And in fact, building and running App works fine. But the designer is now broken for the affected form and shows the error message I mentioned above.
To solve the issue we have to update ProductUILib's NuGet packages as well so that it in turn builds against the latest UILib, and then update App's dependencies once more to get the new ProductUILib. That quickly gets tedious though, especially with more libraries and dependencies.
I tested in both VS 2010 and the latest VS 2013, the new one shows the exact same behaviour.
Do you have any suggestion how we can avoid this issue?
We managed to solve the problem by changing our strategy for using AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion.
We automatically generate the last part of our version numbers on every build, by setting it to the current SVN revision number. This generated version number (e.g. 1.0.0.906) used to go into both AssemblyVersion and AssemblyFileVersion.
The designer apparently takes issue with a mismatch of AssemblyVersion as assemblies with differing AssemblyVersions are deemed incompatible. However, the normal loading process for assemblies without strong name doesn't mind the mismatch, so building and running the program works. So the designer is just a bit more picky.
The solution was to use a fixed value for AssemblyVersion that we will only update on breaking changes. The generated version number now goes to both AssemblyFileVersion and AssemblyInformationalVersion. That last one is important because NuGet will always fill its .nuspec $version$ placeholder from AssemblyVersion unless AssemblyInformationalVersion is present to override it, and we want to generated version number to be used for our NuGet packages.
So in summary:
Only update AssemblyVersion for breaking changes
Use AssemblyInformationalVersion for the number that should go into your NuGet Package
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.
I am using Microsoft.Build.BuildEngine.Engine to build a WPF application. This has been working successfully for class libraries and web applications, but now trying to use it to build a WPF application I am getting the following error:
Target MarkupCompilePass1:
c:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets(294,9):
error MC1000: Unknown build error,
'API restriction: The assembly
'file:///C:\Program Files
(x86)\Reference
Assemblies\Microsoft\Framework\v3.0\PresentationCore.dll'
has already loaded from a different
location. It cannot be loaded from a
new location within the same
appdomain.' Done building target
"MarkupCompilePass1" in project
"TestWindowsApplication.csproj" --
FAILED.
This application builds fine when building using VisualStudio 2008 (i.e. build from the menu), but using the Microsoft.Build.BuildEngine.Engine it throws this build error. Anyone know what is going on here?
I had the same problem and found this on msdn which says
By default, markup compilation runs in
the same AppDomain as the MSBuild
engine. This provides us significant
performance gains. This behavior can
be toggled with the
AlwaysCompileMarkupFilesInSeparateDomain
property. The latter one has the
advantage of unloading all reference
assemblies by unloading the separate
AppDomain.
So since the exception thrown stated that PresentationCore was loaded in the same AppDomain I switched this property using:
projectToBuild.SetProperty("AlwaysCompileMarkupFilesInSeparateDomain", "True");
Which seemed to be the key.
I hope this helps.
Now that is interesting! Check out this issue I hit last week. Same exception and error message, and related to WPF.
If you have a look at the comments for the MSBuild MarkupCompilePass1 task throwing the exception, it may be a clue as to why it's working inside VS2008 but not from your MSBuild process:
<!--
When performing an intellisense compile, we don't want to abort the compile if
MarkupCompilePass1 fails. This would prevent the list of files from being handed
off to the compiler, thereby breaking all intellisense. For intellisense compiles
we set ContinueOnError to true. The property defined here is used as the value
for ContinueOnError on the MarkupCompilePass1 task.
-->