Assume That we have two modules which are using blahblah.dll.
when I uninstall one of them, it delete this dll and cause the second module stop working.
is there any way to mention in manifest file which files must delete after uninstall and which shouldn't?
With the DNN 5.x and later manifest format if you register the shared DLL as an assembly and set a version number to it, it is supposed to be smart enough to not remove it if there are other modules that need it.
Now, I would be sure to check this yourself before relying on it. But otherwise you have the option of going through and creating a third module (Shared Components) essentially that would store the common items.
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.
I'm trying to handle all of User Interfaces (UI) dialogs in .msi installing pakage, with EmbeddedUIHandler to do this I have created a setupui.dll which contains three methods: InitializeEmbeddedUI, ShutdownEmbeddedUI, EmbeddedUIHandler, and put it inside of MsiEmbeddedUI table (using installshield) and it worked just fine.
The problem is when setupui.dll is dependent to other external DLLs, this time windows installer won't use my dll and it uses default ui, I have added other DLL dependencies with Installshield as follow:
I'm uncertain of what Windows Installer allows here. There are, however, three things that jump out at me as things to look into:
The MsiEmbeddedUI table's Attributes column should probably have a 3 for SetupUI.dll (as it does), and 0 for the rest. Per the docs, the 2 bit is ignored if the 1 bit isn't present, but all the other files are better described as "It may be a resource used by the user interface."
The verbose log: does it indicate what's going on? Does it show a failure loading SetupUI.dll that provides a useful error code (hint: file not found probably refers to a dependency)? Does it indicate it didn't even try to load your DLL? Look for lines with EEUI, at least in the successful case.
If Windows Installer does attempt to load SetupUI.dll, how far does it get? If it gets far enough for you to run some code and, say, show a message box, what files are already extracted at that point? If the dependencies are extracted, can you ensure that its directory is on the DLL path via SetDllDirectory or AddDllDirectory? If the dependencies are not extracted, are they present at a later point so approches like delay loading could help?
For the third point, Process Monitor may help you diagnose what's going on if you can't get a message box in there, but it will probably be less clear. Alternately, using Loader Snaps and Debug View might get you a related set of information, but it may be drowned in additional noise.
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.
In the past I've used the solution outlined in the following URL to avoid multiple downloads of 3rd party dlls in modular Silverlight applications:
How to optimize the size of silverlight XAP file by removing common files?
However I am working on a Visual Studio 2010/Silverlight 5 solution application where this is not working.
I have a PRISM module let's call it Parent1.csproj that has no references to my 3rdParty dlls but it does have a reference to two other project files which reference the 3rdParty dlls child1.csproj and child2.csproj
child1.csproj and child2.csproj both have "Copy Local" set to false for 3rdParty.dlls but in spite of this the .xap file for Parent1.csproj contains the 3rd party dlls.
If I set child1.csproj and child2.csproj references in the Parent1.csproj file with "Copy Local" set to false then I get a dramatically reduced xap file with no 3rd party dlls but also none of the other code in the child projects that I actually need to be able to run.
It seems as if included project files get their "Copy Local" setting ignored and use the parent "Copy Local" setting instead, and there's no way for me to exclude those 3rdParty.dlls
Have I missed something subtle here? Is there some other way I can avoid downloading those 3rdParty.dlls in multiple modules when the shell application has already downloaded them?
I'm not 100% sure why this problem occurs, but it is related to Prism. The way we've solved it is add references to all the startup project and each of the sub projects even though they're not directly referenced but that project.
Make sure that the "Reduce XAP size by using application library caching" is enabled for all your projects.
Make sure that Parent1.csproj has references to all your 3rd party dlls.
Add these same references to child1.csproj and child2.csproj.
Double check you have extmap files for all your 3rd party dlls. If these are missing the dlls will be loaded into the XAP files.
Adding the references to the module projects and setting Copy Local to false on them will work, which is more or less what the accepted answer describes. However, Application Library Caching is not supported in Prism modules, so that may not work as expected.
If you have a lot of assembly references, adding them in this fashion is not very maintainable. You could also use a post-build step that removes unneeded assemblies from the XAP. Here's a short article that I wrote about how.
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?