I created a new Metro Split App in C++ using VS2012 on Win8 (both RC). Everything compiled and worked out of the box. I then changed went through and changed the generated namespaces to my own. After some trials and tribulations, I got everything to compile with no warnings, errors, nor messages. The app (as it comes in the project template) runs fine.
However, if I try to edit either of the generated xaml files (ItemsPage.xaml or SplitPage.xaml) I get a "Markup error" on the first line:
The name "LayoutAwarePage" does not exist in the namespace "using:A.B.Product.Client.Common".
The definition of the class is:
namespace A{ namespace B { namespace Product { namespace Client { namespace Common
The code compiles fine, and runs fine. This only happens in design mode.
UPDATE: I added a new xaml file and (after fixing up the namespaces again) everything worked.
Please let me know if any additional information is needed.
The name of the WinMD file produced by your project must be some prefix of the namespaces in which the public WinRT types are defined. Given that your type is in the A.B.Product.Client.Common namespace , the WinMD file must have one of the following names:
A.winmd
A.B.winmd
A.B.Product.winmd
A.B.Product.Client.winmd
A.B.Product.Client.Common.winmd
The public types must also be defined in the WinMD file with the longest prefix that matches the namespace. So, if you have both A.winmd and A.B.winmd, the type A.B.MyClass must be defined in A.B.winmd.
So, why does your code work at runtime but not in the designer? The naming rules for public types only apply to types defined in Windows Runtime components (for C++, DLL files), not for applications (EXEs).
However, to be able to instantiate your user-defined types (including LayoutAwarePage), the designer will load your project's EXE as a DLL, so the naming rules must be followed.
I had a similar bug, but then I closed VS, deleted the .suo, and reloaded the project and everything worked just fine.
Related
in Visual Studio 2017 I have a solution with aspnet core project and about 10 net core libraries referenced to each other.
One of the libraries is xUnit test project. It referenced to another project it should use as aim for testing.
For example I have:
Project: MyProject.Domain
Test Project: MyProject.Domain.Tests
MyProject.Domain.Tests is referenced to MyProject.Domain.
In these projects I have classes with namespaces like project names.
So the strange thing happened when I can use public class from MyProject.Domain WITHOUT using MyProject.Domain.
Can anybody explain it ?
If I understand you correctly, you're wondering why a type in the namespace MyProject.Domain.Tests can access types in the namespace MyProject.Domain without any usings. The reason for that is that the specification says so. From Namespace and type names (edited by removing irrelevant parts):
The meaning of a namespace_or_type_name is determined as follows:
If the namespace_or_type_name is of the form I:
For each namespace N, starting with the namespace in which the namespace_or_type_name
occurs, continuing with each enclosing namespace (if any), and ending
with the global namespace, the following steps are evaluated until an
entity is located:
If N contains an accessible type having name I, then:
The namespace_or_type_name refers to the type.
I have two completely different directories. Directory 1 contains my application and Directory 2 having few assemblies. During run-time when application launches, I will load the assemblies. By default, the executing Assembly's AppDomain will discover the assemblies in Directory 1 (application folder) or GAC. If the file is not there, we will get the error. But I have to extend the AppDomain's search directory to search in Directory 2 also. That is, AppDomain will search Directory1 (local bin), then GAC, then other defaults at last search in Directory 2.
I have tried :
1. By setting PrivateBinPath, but it is restricted only within ApplicationBaseDirectory.
2. By AssemblyResolve, but it is not directly referenced. The AssemblyResolve code never hits also.
Using the AssemblyResolve event is generally the correct way. If it is never hit, it is probably bound to too late. For instance, when the CLR encounters a method, it will compile it completely, resolving all its references. If such resolution fails, it will fail always. If you bind the AssemblyResolve event after any or all assemblies failed binding, the event will never hit.
To resolve this, make sure that the AssemblyResolve event is bound as early as possible. In an executable this is easy enough (first thing in the entry point of your application, or any cctor of a type you use there). In a library this can be harder, best practice approach is to use the module initializer, which is run whenever a module is loaded (most assemblies contain one module).
Since the module initializer cannot be set by C# or any other .NET language I know of, you have to resort to method weaving. I personally like Fody and as it turns out, there's a predefined Fody package called Fody Module Init for exactly this thing.
Just place, somewhere publicly in your library, the following code:
public static class ModuleInitializer
{
public static void Initialize()
{
// bind to the CurrentDomain.AssemblyResolve event
}
}
Fody also works with other languages (you don't specify which you use), but then you'll have to create the static ModuleInitializer class by hand.
Using this approach, you can be certain that the AssemblyResolve event will be called for any assembly that CLR's Fusion cannot find by itself.
I have a project written in MVC2 and VB.NET. I use a lot of htmlhelper extension methods, and I have them all in a public module. They work just fine, and I can compile and run my project. I reference the namespace they are in with this:
<%# Import Namespace="MyProject.WebUI.Extensions" %>
So, again, they work great, my project runs and compiles without a hitch.
The problem is that each one of these extension methods is shown as an error:
Error 33 'TabbedMenu' is not a member of 'System.Web.Mvc.HtmlHelper(Of Object)'. C:\Projects\MyProject\MyProject.WebUI\Views\Shared\Site.Master 23 21 MyProject.WebUI
This doesn't prevent the project from compiling and running, it just creates an error, which is annoying. I've tried looking for solutions, but all of the solutions I've found were for projects that don't compile, all with simple solutions like referencing the right namespace or making sure your module is declared public. Any thoughts?
Have you included an import statement in your site.Master to include the extensions class where your extensions are defined. Also I assume your extension class is a public static class with public static methods defined?
Also check this out if you haven't already, it may be related to what you are after.
How do I use an extension method in an ASP.NET MVC View?
You need to import the namespace where you have placed your extension. And since it is a bit annoying that this problem shows up no sooner than in runtime, you can enable view compilation to have the compiler detect the problem. I should warn you that compiling the views is a time consuming operation though.
I've googled for creation of namespaces and found some very useful examples, what these examples didn't have is how do I compile and implement my created namespace on my system so I can include it from my various applications.
So for example, if I create a namespace to load a config file from my application path and insert it to an array, Do i need to include the namespace on any project I use or is there a way to make it part of my environment?
You're thinking of Class Library (DLL) projects.
When you start up a new Visual Studio project, select Class Library rather than Windows Form project. This will compile your namespaces as a DLL (exposing your public classes), which can be referenced in other projects.
If you want to include a namespace that you created you have to add a reference to your project first. If you have compiled your code into a .dll file, then simply add the reference to the .dll file to your project and then at the top of your classes put the "Imports [Namespace]". If you haven't compiled your namespace, add the project (with the namespace that you created) to your solution, add the reference to it (under the Projects tab), and then use the Imports statement.
You are confusing the concept of a namespace with the concept of a project, especially of a class library project.
A class exists within a namespace. If no namespace is defined, then the class still exists within the global namespace (the one with no name).
In any case, it's classes that do the work. Namespaces are only so that you can have a class named Book, and I can have a class named Book, and so that TriDat.Book can exist at the same time as JohnSaunders.Book.
I'm getting a compiler error saying that "Acme.Business.User" is not defined.
I have a class library project called "Acme.Business" that has "Acme.Business" as the assembly name and root namespace as well. None of the classes use the "Namespace" keyword, so they all should exist in the namespace "Acme.Business".
I also have a class library project called "Acme.Web" that has a project reference to "Acme.Business". Again "Acme.Web" is the project name, assembly name, and root namespace.
Here's the weird part. If I add a class to "Acme.Web" I can type "Imports Acme." at the top and see both namespaces appear in intellisense like you'd expect, but if I try to do "Dim x as New Acme.Business.User" then "Business" doesn't show up in intellisense and I get an error saying "Acme.Business.User" is not defined.
I can't see what I'm doing wrong! Please help. Thanks.
I think you may be misunderstanding how project default namespaces work. The default namespace is a project file setting that simply tells Visual Studio what namespace to add to each file when you add a new class file to the project. If you have removed all of these namespaces from the code files then your types do not exist in that namespace.
This means that all of your types in the Acme.Business assembly live in the global namespace which is probably not what you want. In order to get the desired behavior you will need to add the namespaces back into your code files as that is the only way the compiler will create type names with that namespace.
OK, I figured out that the behavior I was seeing was because I was declaring namespaces within the code in Acme.Web the way I was used to in C# which is to fully qualify it, ie. Namespace Acme.Web.UI.WebControls. I didn't realize that in VB.NET it's building on top of what was specified for the root namespace. I removed the portion that was specified in the "root namespace" setting of my project and it started working. So my namespaces in code for Acme.Web now look like Namespace UI.WebControls.