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.
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?
In a Visual Studio 2010 solution, I have 2 projects:
Project A which is a dll project
Project B which is an executable project and depends on project A (configured through the solution project dependencies properties)
When I add new APIs in project A declared with __declspec(dllexport) specified and call them from project B.
If I simply "Build" the project B, it turns out that project A is built then project B but the linker does not find the new APIs and report them as unresolved external symbols.
Now if I "Rebuild" the project B, the solution is fully rebuilt and I do not have unresolved symbol linker errors.
Any idea what could cause the builder to not find the new symbols using a simple Build action and how to fix this?
Pretty hard to explain this with the info you provided. It clearly strongly suggests a build order problem, even though you documented that A gets built first.
You may have a problem with the parallel build feature available in VS. If it doesn't see any dependency between projects then it allows projects to build concurrently, taking advantage of your machine having multiple cpu cores. You can see A starting building but B starts building right away as well. Indicated with a numbered messages in the Output window, preceded with 1> and 2>.
If there actually is a dependency then it becomes a race. If B progresses to the link stage before A is done linking then it will certainly have trouble. But that is typically announced by it complaining it cannot find the import library for the DLL project. It finding an old version of A.lib that is missing some identifiers would be an unusual corner case. Things do however get interesting when it finds A.lib while it is being written. Which does explain what you observed.
Best thing to do is to ensure that VS knows there is a dependency without relying on it figuring it out by itself. It is not very good at figuring this out for C or C++ projects. Right-click your B project in the Solution explorer window and click "Project dependencies". Tick the A project. Now it will no longer build concurrently, B won't start building until A is done. Which is essentially what you did by hand to work around the problem.
If you still have trouble then you'll need to suspect other programs on your machine, the kind that mess with files. Anti-malware software is always on the top of the list of troublemakers like that. Avast is especially notorious for giving VS a hard time.
I have a question does it happens every time? It should not. Build command links, create binaries, find resources depending on the existing resource. No, if you change any resource like library, images form designs etc. Then you need to rebuild (clean+build).
To make a project build before another project build. You have to add dependency by this:
Right click to solution>properties.
Go to Project Dependencies > Select the project and tick the dependent project.
Finally right click to your project B select Set as StartUp Project.
This will force your project to build sequentially.
If I add the RX-main package to a WPF application I get the following dependent packages installed:
Rx-Interfaces
Rx-Core
Rx-Linq
Rx-PlatformServices
Rx-Main
After adding Rx-main there are two additional packages related to WPF that can be installed
Rx-XAML
Rx-WPF
Rx-Xaml is dependent on Rx-Main, and Rx-WPF is dependent on Rx-Xaml. However both of these packages add a reference to System.Reactive.Windows.Threading. What if anything is the difference between them, and why are there two separate packages that add a reference to the same assembly?
Also, do I need to add either or both to be able to use RX in WPF?
I actually know the answer to this, as the former owner of the Rx-Xaml package. It used to be that there were only Rx-Silverlight and Rx-WPF. This made it difficult to create packages like ReactiveUI, since they had a dependency on one or the other depending on which platform you're using.
So, I created Rx-Xaml, which was literally just a merging of Rx-Silverlight and Rx-WPF. However, the Rx team realized that having separate packages was silly, and asked me if they could take over the name for themselves. I gladly obliged, and now Rx-Xaml is the package you should be using. Rx-Xaml since 2.0 is owned by Microsoft.
tl;dr: Use Rx-Xaml, ignore Rx-WPF and Rx-Silverlight, they're old and busted.
From what I see using NuGet Package Explorer, neither Rx-WPF not Rx-Silverlight include any DLL of their own (or any other file, as a matter of fact) in their respective nupkg files. Therefore they seem to function only as a container for Rx-Xaml. My guess is that you should still point to Rx-WPF since the Rx team might start adding specific logic to it which would not be contained in the base Rx-Xaml package.
I am trying to apply this bug fix http://code.google.com/p/selenium/source/detail?r=11856 to the selenium-server-standalone-2.0b3.jar.
Does anyone know where I can get the source code? The jar only contains class files.
Or if there are alternate ways of getting what I need, please do tell.
Thanks,
-Denali
You should be able to check it out from SVN:
Use this command to anonymously check out the latest project source code:
Non-members may check out a read-only working copy anonymously over HTTP.
svn checkout http://selenium.googlecode.com/svn/trunk/ selenium-read-only
I am not entirely sure how this project branches their code, but I assume it would be a branch in the project for a release.
I have a WPF project which compiles just fine. However, when I enable code contracts, I get a lot of errors like the following:
file 'C:\MyProject\obj\Debug\MyFile.g.i.cs' could not be found
Is there workaround?
Just FYI... This bug has been fixed in the latest version of Code Contracts (v1.2.21023.14, released Oct. 22nd).
Can you be a bit more specific about your repro steps? The significance of the files ending in .g.i.cs is they are files generated specifically to enable intellisense in running projects. They are not truly part of the build process and likely should not be consumed by code contracts. I'm not a code contracts expert by any means though so I could be wrong on this point.
I posted a repro and workaround to this problem on the Code Contracts forum. Here's the URL:
http://social.msdn.microsoft.com/Forums/en-US/codecontracts/thread/4f2af748-1db1-4175-abf0-fbcc82f177ee
The short answer is that the error occurs whenever you have multiple projects that reference each other in a Solution, and one of the child projects is a WPF control library. To get around the problem, you can either disable contract verification for the parent project(s) (the ones that reference the other projects), or you can add a post-build event to the offending child project(s) to create the *.g.i.cs files that the Code Contracts rewriter is looking for.
For example, create a blank text file in the root directory of your child project and name it "Blank.txt". Then add the following command as a post-build event in that project:
copy "$(ProjectDir)Blank.txt" "$(ProjectDir)obj\$(Configuration)\GeneratedInternalTypeHelper.g.i.cs"
Copy this line as many times as needed, one for each missing file.