I am creating setup through installshield in vs 2012. When running the setup at client side then throwing below error:
Could not load file or assembly 'Telerik.WinControls.Themes.Aqua, Version=2013.3.1016.20, Culture=neutral, PublicKeyToken=5bb2a467cbec794e' or one of its dependencies. The system cannot find the file specified.
Anybody can help to sort out the issue.
Thanks,
You need to include that file 'Telerik.WinControls.Themes.Aqua' in your InstallShield installer. I am not sure based on what you asked if that you are directly referencing that dll or that one of your other Telerik controls is implicitly referencing.
Any reference that you have in your projects references must be included in your installer. Those dll's may also have implicit references that will not show up in your References. Usually in the help documentation of most 3rd party vendor controls is a section about deployment to clients. They will usually list what are the implicit references of what to include with your project.
Related
I had to have my primary HD replaced. Yesterday my HD was replaced by our IT tech staff. So today, after installing VS 2015, I started working on a WPF app we've been working on. I got into the project, did a Get Latest from TFS and did a build. I failed with the following error:
Cannot resolve dependency to assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' 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.
First of all, I've no idea why we even need System.Web. Secondly, it isn't in the references of any project in the solution. I know, I've looked, but in VS 2015 AND opening the .csproj files directly. So, what is trying to use it? What needs it? At this point I'm about ready to add it for no other reason then just to make it build.
why we even need System.Web. Secondly, it isn't in the references of
any project in the solution. I know, I've looked, but in VS 2015 AND
opening the .csproj files directly. So, what is trying to use it? What
needs it?
System.Web.Dll is old library responsible for whole http-protocol working. requests sending and creation. And you can find the system.web is member of system:
Besides, we can find the detail build log in the Visual studio Output, the system should be loaded, so if that assembly is missing or it is with a different version compared with the other referenced binaries, the assembly could not be loaded.
To resolve this issue, you could add it or create a new project with Visual Studio 2015 and copy the source files into this project. Then rebuild it, check if it works.
Hope those can help you.
Adding MVVM Light reference to a WPF projects adds a large number of system assemblies to the list of dependencies in the accompanying MSI Setup project. These assemblies (50+ in number) are then copied to the application folder when the app is installed. Why is it so? Why can't it reference it from GAC directly?
Note: Copy Local option is set to True for MVVMLight.dll. I obviously can't set it to False.
Reproducing it is extremely simple. I'm using VS2015 Community.
Create a new WPF Application project.
Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
Add an MSI Setup project to the solution (must have the extension installed).
Add Primary Project Output of WPF application to the setup project.
There you go. A long list of System.X.Y will be added to the list. If you build and install the setup project, you'll see all these DLLs in Program Files folder.
Why? And how to fix it?
Update
The problem does not appear if WPF application targets .NET Framework 4.0 and you add NuGet reference AFTER that. But if you target .NET 4.5, 4.5.1 or 4.6, the long list of dependencies appears again. Think MVVM Light (or NuGet) is having trouble finding the correct package sub-folder.
I don't know why it happens but I can offer a workaround. Just open the project's Detected Dependencies folder, select all of the System dlls, right-click and select Exclude.
Overly agressive dependency scanning is one of the many reasons I don't use Visual Studio Deployment Projects. Instead I use WiX / IsWiX. Both open source and the later written by myself.
For more information see:
http://www.github.com/iswix-llc/iswix-tutorials
I am trying to publish a WPF application using the publish section in the project properties. When I attempt to specify application files (i.e. references) for the publish, I see lots of old dlls that were once in the project but were deleted later.
Is there a way to clean up this list so that it matches the references actually used in the project ?
It is not possible without extensions. However you can check this question for more details. There are also some extensions listed you could use.
I've got this error that I just can't figure out.
I'm using VS 2012 (VS11) on Windows 8 with .net4.5 and I get this error when compiling a project that worked with VS 2010 and .net4.0.
This is the full error:
The type System.Windows.Input.ICommand exists in both 'c:\Program
Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\PresentationCore.dll'
and 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.dll'
If anybody could provide some insight on what is causing it and/or how to fix it I'd be grateful.
Thanks.
c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.dll
The message is accurate, ICommand indeed exists in both assemblies for .NET 4.5. The problem is your reference to System.dll, your project is using the wrong one. The assemblies in the Microsoft.NET directory are no longer suitable to act as reference assemblies, like they were in versions of .NET prior to .NET 4.0. They should no longer be there but unfortunately are required to get C++/CLI projects built.
Your reference to PresentationCore.dll is correct, it uses the c:\program files\reference assembly subdirectory. The proper home for reference assemblies in .NET 4.0 and up. These assemblies are special, they contain only metadata and are not a copy of the runtime assemblies.
You'll need to fix your project. System.dll is probably not the only assembly that has this problem. Open the References node of your project and verify them one by one. Remove bad ones that point to Microsoft.NET and replace them with good ones by using Project + Add Reference. Best to just replace them all to be sure.
I had a similar problem with fxcopcmd V12.
I was able to solve it by explicitly adding
/reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\WindowsBase.dll"
See: FxCop engine exception on WPF assembly
Take a look at this similar post, How can I resolve this? The unit type exists in two dll files, it suggests that you are referencing two assemblies with the same type, so you would need to give the type you want to use the fully quantified name.
We had the same problem with our libraries after moving to a new build server.
The solution was to specify the path of the .net framework to build against:
/p:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
If the .net 4.0 framework (Multi-Targeting Pack) is not installed on the build server (as it was with us), you can just copy the "v4.0" folder with all its assemblies to the build server ;)
Recently, I've started to encounter exceptions in the Visual Studio 2010 WPF designer seemingly due to log4net. If I freshly build my project, the XAML file will appear correctly in the designer. Then, once I start to click on controls to jump within the XAML, this exception quickly gets thrown:
System.Reflection.Adds.UnresolvedAssemblyException
Type universe cannot resolve assembly: log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821.
at System.Reflection.Adds.AssemblyProxy.GetResolvedAssembly()
at System.Reflection.Adds.AssemblyProxy.GetHashCode()
continues...
The problem only goes away when I remove the log4net reference. This is now the second project to exhibit this behavior. Has anyone else seen this and/or found a fix?
Note: I'm using .NET 4 Full (not Client Profile) and I've toggled Specific Version on the log4net reference T/F to no avail.
I managed to resolve the issue after:
Finding this blog where the author resolved a similar situation by placing the unresolved assembly in the Public Assemblies folder (found using k3b's fuslogvw tool)
Encountering a FileLoadException which led me to this SO post.
Downloading a fresh copy of log4net, unblocking the zip file, and replacing the reference in VS and the Public Assemblies folder.
But, I'm still not sure why I had to place this particular assembly in the Public Assemblies folder. All the other assemblies I reference don't require this step.
You can use the "Assembly Binding Log Viewer" (Fuslogvw.exe) that belongs to the dotnet sdk to find out which dll is loaded when and why . If logging is enabled it can show you wich assemblies are loaded and which assembly caused it to load.
For details see http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.80).aspx
Sometimes the dll is there but in the wrong version.
if you include universe.dll into your project you must also include log4net.dll with local copy=true
Add the path to your assembly "log4net" in the Project Properties/Reference Paths.
http://msdn.microsoft.com/en-us/library/6taasyc6(v=VS.100).aspx
Turns out when we had this problem, it was due to the paths we used to add the references.
We are using some custom ".targets" files which define the references. There are lots of mixed dependencies with the projects, and using the .targets files helps to keep the references defined in one place.
Well, the references HintPath ended up something like...
<HintPath>C:\Program Files (x86)\\Custom\CustomControlsWPF2.2011\Source\\..\Binaries\WPF\Custom.Windows.Controls.dll</HintPath>
When we removed the double blackslash, replacing with single "\", the "Visual Studio 2010 UnresolvedAssemblyException: Type universe cannot resolve assembly" error went away.
This is how is should have been.
<HintPath>C:\Program Files (x86)\Custom\CustomControlsWPF2.2011\Source\..\Binaries\WPF\Custom.Windows.Controls.dll</HintPath>
Ensure that your code runs at design time, as well as run time. If your code runs at design time, do not assume that Application.Current is your application. For example, when you are using Expression Blend, Current is Expression Blend. Typical operations that cause a custom control to fail at design time include the following.
-Casting Current to your custom subclass of Application.
-Using the FindName method on Current.
-Not checking whether Application.Current has returned a value that is null. If Visual Studio does not create an application object, then Application.Current may return null.
http://msdn.microsoft.com/en-us/library/ff356886%28v=vs.95%29.aspx
give a try to this. add it at the beginig of your functions:
// Check for design mode.
if ((bool)(System.ComponentModel.DesignerProperties.IsInDesignModeProperty.GetMetadata(typeof(DependencyObject)).DefaultValue))
{
return;
}