Changing assembly name broke xaml namespace - c#

I have some application named Application.exe. I use it for showing a different type of documents. Each document type template is a single dll-file with wpf user controls and business logic inside. So when I started my application, I download xml-file and Template.dll and then I show some wfp-form for work.
My Application.exe and Template.dll both use some assembly named Application.CustomControls.dll. I include it in setup project for application, so Application.CustomControls.dll is already in the application domain when my Application.exe tries to show the document.
Now my client demands to change Application.CustomControls.dll name to CustomControls.dll. Don't ask, please. Just assembly's file name, not namespace or something.
I can do it for application without problems. I can rebuild a solution and create setup project with newly named dll-file. But I can't open old templates case they all have old name inside. Especially in xaml like:
xmlns:Controls="clr-namespace:CustomControls.Design;assembly=Application.CustomControls"
I can't just rebuild all templates. It will be done, but in prod, there is always will be the time when some users forgot to upgrade their soft and so on. So either old application couldn't open the new template, or new application couldn't open an old template.
I didn't change namespace, or version of Application.CustomControls.dll just name. Could I somehow resolve these problems and rebind assembly link inside the application? With AppDomain.AssemblyResolve event or config-file?

Related

Could not find type” error loading a form in the Windows Forms Designer

I have a windows form where I have created my own custom comboBox code .cs class file in my project and used that in my form controls.
This works fine for the exsisting project where its been created.
Problem:
The same form and controls needs to be inherited in an another project(solution)...
When I copied mycombo.class file and the rest of the forms to the other project solution I get the below error....
Could not find type 'namespace.MyCombobox'. Please make sure that the assembly that contains this type is referenced. If this type is a
part of your development project, make sure that the project has been
successfully built using settings for your current platform or Any
CPU.
The variable 'comboBox_BusinessType' is either undeclared or was never assigned.
It is working fine when running the file but when I open the desiner.cs file the error is occuring particularly for the combobox controls in the designer.cs files of all the forms copied.
Is there any soltuion for this issue ? Please let me know if any further information is required to solve this one....

WPF Project with Custom XAML Controls

I am new to WPF coding. I have a project that has custom controls coded as xaml's with C# code-behinds. I try to import these files into another project and when I try to use these xaml controls in my main view file, Visual Studio cannot find the namespace that the imported xaml's and C# code-behinds are attached to.
I tried changing the namespace to be the same as my current project. I tried restarting Visual Studio 2013. Neither of these worked.
I tried adding the project with the custom controls to my solution. The imported project can read the custom xaml's, but my main project still can't reference them. I tried dragging the files over to the main project, and they still won't work.
I tried rebuilding the controls xaml's and C# code-behinds in my new project it still says:
The type 'local:ClickSelectTextBox' was not found. Please verify that that you are not missing an assembly reference and that all reference assemblies have been built.
This item is under the appropriate namespace and in the current project.
In visual studio go to TOOLS -> choose Toolbox Items. this will allow you either choose from an array of different components or browse around to find a dll that you would like to use.
EDIT:
Oh so you are trying to take customized xaml files that you already have written and modify them in a separate project? I would suggest one of two things.
1: right click your project name -> add existing, and add the xaml and xaml.cs file to your project at the same time.
if for some reason that does not work you can also try
2: creating a new xaml control (with the same name of the control you want to drop in) in your project and copy pasting the xaml code into that control, this should autogenerate the codebehind designer shell you are going to need. you can then go into the xaml.cs file and drop whatever business logic you are looking for. It is not the cleanest solution but sometimes the WPF editor gets a little funky when importing xaml files
I know it's an old post but still somebody may find it useful:) So! ... Make sure
1)You don't have public class outside of root namespace, check this
link
2)You are not mixing targets of your assemblies (unless you can't 100% avoid that)
For example, if you are referencing something like SQLite.Core NuGet (that has both x86 and x64 versions of SQLite.Interop.dll built in) in a project that is AnyCPU, sometimes it's easier to set application's target to x86 or x64 to solve the x86/x64 paths issues - but then you may get all these "type not found/control not built/assembly not found" and all that sorts of nonsense from Designer even despite your app builds and runs ok.
Hope that helps
Try downloading ReSharper's trial version, install it and then open up your code again. One of the awesome features Resharper has with XAML code is that it will automatically map objects to their appropriate namespace. I think this will make it easier for you and will show you a ton of ways to do things better. When I was first learning WPF it was honestly a godsend to use Resharper.

App works on my computer but not colleagues - Could not load file or assembly or one of its dependencies

I have a wpf application that runs on my computer fine.
The application opens on a colleagues computer but when he clicks one of the buttons an exception appears.
The exception is
Could not load file or assembly 'ABC, Version=1.0.0.0, Culture=netural, PublicKeyToken=null' or one of its dependencies
My application has two projects, ABCWPF & ABCLibrary. I had a console application which was called ABC.
I made a copy of this project and changed the output type to Class Library. I renamed all the folder names from ABC to ABCLibrary as well as the two files below,
ABC.csproj renamed to ABCLibrary.csproj
ABC.user renamed to ABCLibrary.user
I also updated one line in the solution file for ABCLibrary shown below. Please note I didn't change the GUID's I read that visual studio will automatically do that.
Project("{Some GUID}") = "ABCLibrary", "ABCLibrary\ABCLibrary.csproj", "{Some GUID}"
In the properties page of ABCLibrary on the application section the Assembly name & Default namespace are both ABC.
Why will this run on my computer by not my colleagues?
Update
I've just used the fuslogvw. Looking at the log file for the assembly that is giving my colleague issues (ABC) and it says the bind result operation completed successfully, no issues that I can see
Another Update
So it works on my other colleagues computer so its appears to be this one computer (the one it really needs to run on). I did notice something (probably nothing but not getting anywhere) in windows explorer the app has an icon but on the computer that it isn't working on it has the visual studio default icon.
Update 3
So it works on some of my colleagues computer and other it doesn't. Is the error message telling me that there is a file in the assembly ABC that cannot be loaded? If so they only reference I have added is a Bloomberg reference which every users uses everyday so not sure what is going on
There could be any number of problems why a computer can't load an assembly. Some reasons may include:
The .DLL file doesn't exist in the application folder structure
The .DLL file should be in the GAC, but isn't
The .DLL file could have a different name than expected
The .DLL file could have a different signature and so the CLR refuses to load it.
The .DLL could be compiled with a version of .NET incompatible to the calling library (i.e. .NET 3.5 calling a .NET 4.5.2 library).
I recommend you use the Assembly Binding Log Viewer (Fuslogvw.exe) to see the details of what's happening on the computer:
Open the command prompt as an administrator
Type fuslogvw in the command prompt
Click on Settings
Check the box that says "Log Bind Failure" or "Log all Binds"
To learn more about how to investigate a bind failure see Fuslogvw's page at MSDN
Have you tried using FusionLog? FusionLog would give you all the paths that the Loader tried searching while loading the dependencies. Look at this link on how to turn on the fusion log.

Winforms Designer, C# Project with VC++ references, working directory issues

I'm working in a solution with ~100 project (of mixed C# Winforms, VC++ Winforms, and Unmanaged C).
I have a project, named 'DatafiltersControls' (C#), which has a references to a project named 'DatafiltersTypes' (VC++), shown below is the xml entry for the specific reference.
<ProjectReference Include="..\DatafiltersTypes\DatafiltersTypes.vcxproj">
<Project>{360679FF-815C-4B39-8E5A-62C0D2A6DB31}</Project>
<Name>DatafiltersTypes</Name>
<Private>False</Private>
</ProjectReference>
Now, the problem: "The designer will only load my controls under certain circumstances". After doing a lot of research, i've broken it down to my development environment, and the way I open my solution. My build environment is created from inside a dos window, which will subst a new drive (P:), mapped to a directory.
After my directory is created:
If my prompt is has "p:\common" as the current working directory, and type common.sln, all designers work great with no issue. This was the current working directory when I initially set that reference in the first place.
If I doubleclick on common.sln from explorer, and then try to open a 'complicated' form, I get the following error: Could not load file or assembly 'DatafiltersTypes, Version=1.0.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified
If my prompt has "p:\" or any other directory as the CWD, and then invoke "p:\common\common.sln", the designer breaks on complex forms (same as above)
I believe the specific problem is this: my references where added relatively, based on the CWD when visual studio was opened. From that point on, the designer breaks on any 'complicated' form, because the search path is based on the cwd.
If needed, I can define 'complicated', I have the exact circumstances. My ideal solution would to allow my references to be based on the root of the drive (its a constraint developers at my company already have anyways). For instance, instead of
....\build\output\datafilterstypes.dll, I want \build\output\datafilterstypes.dll as my reference.
Its important to note that: Everything compiles just fine regardless of my working directory when I load devenv, its just the designer.
Thanks in advance.
Edit: To add, I have the same issues if the
The problem is the designer cannot load C++ dll's that aren't pure. Convert any project that will directly, or indirectly, a C++ dll to be pure.

How to preserve app settings from a referenced assembly?

I have an app MainApp that references another project MyDLL.dll. Inside the MyDLL project I have made some user settings in a Settings.settings file that may be changed at runtime. So it appears that these settings get saved in the app.config file of MyDLL. But the problem is, the main project is MainApp, and MyDLL.dll.config does not, so far as I can see, get copied to the MainApp output folder. This is reflected in the fact that even though I save the settings in the code of MyDLL, the next time I run MainApp the settings have gone back to the default.
I must be missing something really obvious here. There has to be a way for related assemblies to preserve their settings values. But how?
While you can add an app.config to a library project, it has no effect to do so. Configuration is linked to the application, not the library.
You need to create the settings and configuration in your application itself. You can do something like including the library's app.config if you really wanted to, but that would probably not do what you want, either. It's best to just handle your configuration in the application.
Why is this so? Because what's to say it's valid to have user settings for your library in the first place? A library should not be tied to any particular kind of application. What if you used it in a Windows Service or an ASP.NET application?

Categories

Resources