I have an ASP.NET 3.5 web application project in which I'm trying to implement a searchable gridview. I originally started the project as a web site and converted it to a web application. After conversion, my class ended up in the folder Old_App_Code and is called SearchGridView.vb.
Imports System
Imports System.Collections
Imports System.Collections.Generic
Imports System.ComponentModel
Imports System.Text
Imports System.Web
Imports System.Web.UI
Imports System.Web.UI.WebControls
Imports System.Drawing.Design
<Assembly: TagPrefix("MyApp.WebControls", "SearchGridView")>
Namespace MyApp.WebControls
#Region "TemplateColumn"
Public Class NumberColumn
Implements ITemplate
Public Sub InstantiateIn(ByVal container As System.Web.UI.Control) Implements System.Web.UI.ITemplate.InstantiateIn
End Sub
End Class
#End Region
<ToolboxData("<{0}:SearchGridView runat=server></{0}:SearchGridView>")> _
<ParseChildren(True, "SearchFilters")> _
Public Class SearchGridView
Inherits GridView
The class file continues, but this is the first part of it.
Unfortunately, I receive the error message
Warning 1 Namespace or type specified in the project-level Imports 'MyApp.WebControls' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases. DielWebProj
In web.config, I included a namespace tag for MyApp.WebControls and I included an imports tag in the .aspx page as well.
Can anyone shed light as to why this error is being raised and how I would remedy it?
Thanks,
Sid
I have a broadly similar problem to you. I have a website project using a custom control, inheriting from GriView, in the app_code folder. I was recieving the very same error, but noted that it happened only after I would add a second class or module to app_code, and would disappear if I removed it.
So the workaround I have at the moment is to just leave my custom control as the sole occupant of app_code.
One option might be to make the control part of its own project and add it as a reference to the we site/app?
I'll update this if I can find a decent solution.
EDIT:
Well, in my case it was because the control I was using was written in C#, whereas the rest of the project, and classes I added to app_code, were in VB.
The app_code folder is compiled to a single assembly, so classes of different languages cannot share it, unless you create seperate sub-folders and do some config file jiggerypokery. More details here
Related
For example, I have two files called file1.swift and file2.swift.
file1.swift:
import UIKit
class A: B {
}
file2.swift:
import UIKit
class C: A{
}
I am reading that public class can not subclassed outside of module. Here I have subclass C. I am trying to understand what does module mean here. I imported to same module UIKit for both file. So the both files are of same module? So that I can subclassed. Or both files have different module even I import the same UIKit?
Can anybody explain what is module?
Source:
Classes with public access, or any more restrictive access level, can be subclassed only within the module where they’re defined.
Class members with public access, or any more restrictive access level, can be overridden by subclasses only within the module where they’re defined.
A module is a single unit of code distribution—a framework or application that is built and shipped as a single unit and that can be imported by another module with Swift’s import keyword.
Each build target (such as an app bundle or framework) in Xcode is treated as a separate module in Swift. If you group together aspects of your app’s code as a stand-alone framework—perhaps to encapsulate and reuse that code across multiple applications—then everything you define within that framework will be part of a separate module when it’s imported and used within an app, or when it’s used within another framework.
As the docs indicate, the module is an application or a framework (library). If you create a project with classes A and B, they are part of the same module. Any other class in the same project can inherit from those classes. If you however import that project to another project, classes from that another project won't be able to subclass A nor B. For that you would have to add open indicator before their declarations.
Basically, if you work on a single app then you are working in one single module and unless declared as private or fileprivate, the classes can subclass each other.
EDIT
Let us have following class in module (project) Module1:
class A {
}
Since this class is not open, it can be subclassed only within the same module. That means that following class:
class B: A {
}
Can be written only in the same project, in Module1.
If you add Module1 as a dependency to project Module2, and try to do this:
import Module1
class C: A {
}
It will not compile. That's because class A is not open (in other words it has access public or less) and it does not belong to the same module as C. A belongs to Module1, C belongs to Module2.
Note
import keyword imports a dependency module to your current module. If you write import UIKit in your project, you are telling the compiler that you want to use module UIKit in your module. import does not define current module. Current module is the current project.
Adding import UIKit at the beginning of the file does not change nor define to which module the file belongs. It just tells the compiler that in that file you want to use code from UIKit module.
Swift module(.swiftmodule)
History:
[#include -> #import] -> [Precompiled Headers .pch] -> [#import Module(ObjC);] -> import Module(Swift)
There are two type of Module - folder and file
.swiftmodule folder. Folder contains all .swiftmodule files for architectures and other meta information like:
.swiftmodule file. It is binary file format which contains Abstract Syntax Tree(AST) or Swift Intermediate Language(SIL) of framework's public API.
.swiftdoc - attached docs which can be revived by consumer
.swiftinterface - Module stability
[.swiftinterface or Swift Module Interfaces] is a next step of improving closed source compatibility
When you Jump to Definition of imported module actually you reviewing public interface of .modulemap
Binary(library, framework) can contains several modules, each module can contains a kind of submodule(from Objective-C world) thought.
import struct SomeModule.SomeStruct
These modules can have dependencies between each others.
Module is a set of source files which solves the same problem that is why they can be grouped under the same model name.
Module helps to group sources to reuse them
Module helps Xcode to minimize build time(open source)(If module was not changed it should not been recompiled)
Also Module is a kind of scope which can help compiler to figure out which exactly class to use. If two modules use the same name you get
Ambiguous use of 'foo()'
It can be solved by:
import ModuleName1
import ModuleName2
func someFunc() {
ModuleName1.SomeClass.foo()
ModuleName2.SomeClass.foo()
}
I have a maxforlive device using java/mxj.
I used all of these options to include my java files during development:
Including my (maven) target/classes directory through max.java.config.txt.
Adding a directory through Options > File Preferences
Adding a jar to the automatically generated (OSX) ~/Documents/Max 7/Max for Live Devices/MyProject Project/ directory
All of these paths work fine i.e. the files are picked up and my mxj object works.
However, when i freeze the device for publication, java files are not included from any of those paths.
I tried to make sense of
https://docs.cycling74.com/max7/tutorials/jitterchapter99_appendixd although I'm not building a standalone, but a freezed maxforlive device, so I included max.jar and mxj.mxo in the Project folder which did not work either.
When I copy my target/classes or target/classes/myproject folder into the generated Project folder (/code, /code/classes, /classes), max moves all the class files out into /code, creating a lot of work for me while not even picking the classes up for dev.
I saw devices on maxforlive.com with properly included java files, so I know it can be done. How can I achieve this?
Unfortunately this is a long standing bug in MFL.
Here is a movie from 2012 where I reproduce this, it has not been fixed since. http://arttech.nl/projectjavaissue.mov
This means that the only way to distribute MFL devices with java class files is to include them separately.
Ok, so here it is: Including just a single class with no other class dependencies except MaxObject works fine. There's also no need to add .java files like I said in my previous comment.
All you need to do is:
have the working mxj object in your patcher (doesn't matter where you saved it)
click the button on the bottom that says "Show containing project" on hover
add your classfile
freeze
When you have more classes, it gets complicated.
1) If you have your typical java hierarchy with folders and subfolders, that won't work. As you have to add each file separately, the hierarchy will be destroyed. Use a jar and add it to the containing project.
2) Here it comes, believe it or not: All the classes you are going to use will have to be loaded on first instantiation. I call it static class allocation ;)
A way to achieve that:
create a new instance of every class in the constructor of the class that extends MaxObject or any other constructors it calls. That includes classes with only static methods.
if you happen to use interfaces and create implementations of those dynamically (new Runnable() {...}), don't. Dynamic implementations are new classes.
Fun fact: you can override methods of classes, too. So go
class Runner {
public void run() { throw new Exception("not implemented"); }
}
then you can dynamically create a
new Runner() {
public void run() {
MaxObject.post("Even Mr. Gosling says interfaces were a mistake!");
}
}
Don't believe it? I don't blame ya. Look at
https://github.com/mihop/mxj-wsserver
and
http://www.maxforlive.com/library/device/3809
to be converted.
I created a bunch of classes and packages in the USER namespace for prototyping. Now I need to move all of these classes into a different namespace. When I export/import the classes from the USER namespace to another namespace, the package directory tree is not created correctly. For instance:
Classes / Package1.SubPackage1.SomeClass
gets created in the namespace like this:
Classes / Package1.SomeClass
I also noticed that it stripped off Package1. from the original object I exported.
What's the trick?
I used Ensemble's Studio for above...
I have a C# application that I am trying to re-create through the use of CodeDom. This application has four classes inside of it. If I were to go into this applications directory, I would find the project file (App.csproj), and if I were to start this project file, all four classes would load together. Furthermore, if I were to build this application, all four classes would build together.
My Question: How on earth can I create this functionality through the use of CodeDom?
I have sucessfully created one of the four classes using CodeDom, but how can I go about creating the next three classes (and linking them) to the first class that I already created?
I know this may sound confusing but I will explain more if necessary.
If the classes are in the same namespace you can add them all to one CodeNamespace object and generate the code from that.
If there in different namespaces you can add the namespace of the other Classes to your first class by adding the namespaces reference of the other class's to the namespace object you are working in:-
// Add the Namespace of the other class to the current namespace onject
defaultNameSpace.Imports.Add(new CodeNamespaceImport("Project.Namespace.Namespace"));
Where defaultNameSpace is a type of CodeNamespace. The first Class you have built is added to this CodeNamespace object as below and then the code is generated from that :-
defaultNameSpace.Types.Add(mainClass);
mainClass being a type of CodeTypeDeclaration.
Hope this helps.
In a new WPF project (VS2010) i 'm using Unity 2 for the first time.
In this project i use the following structure:
Solution
WPF Project
Class Library1
Class Library2
Class Library 3 ....
Registering the different types using Unity is done in WPF Project using the following snippet:
IUnityContainer container = new UnityContainer()
.RegisterType<IObjectContext, ObjectContextAdapter>()
.RegisterType<IConnectionStringProvider, ConnectionStringProvider>()
.RegisterType(typeof(IRepository<>), typeof(Repository<>));
Let's say now that i would like to get the Repository<Orders> constructor-injected resolved in Class Library1.
Apparently the container is not known in the other projects!
How would i do that?
I mostly agree with Chris' answer, but I think config files are icky (especially for Unity) so here's a solution that will allow you to use runtime config w/o circular references. We're going to do this with registries.
Create an Infrastructure project that will contain IConfigureUnity.
public interface IConfigureUnity
{
public void Configure(UnityContainer container);
}
Each of your class library projects will be responsible for implementing this interface to register it's own classes.
public class RegistryForSomeClassLibrary : IConfigureUnity
{
public void Configure(UnityContainer container)
{
container
.RegisterType<IObjectContext, ObjectContextAdapter>()
.RegisterType<IConnectionStringProvider, ConnectionStringProvider>()
.RegisterType(typeof(IRepository<>), typeof(Repository<>));
}
}
Then in your WPF project you'll need to create the container and apply these registries.
var container = new UnityContainer();
new RegistryForSomeClassLibrary().Configure(container);
new RegistryForAnotherClassLibrary().Configure(container);
Now you have a fully configured container instance w/o any config files.
To have multiple projects make use of the same UnityContainer in this scenario, you need a "common" project that contains your UnityContainer and exposes it such that all other projects can access it.
i.e.
WPF Project
Class Library 1
Class Library 2
Class Library 3
Common Library (UnityContainer lives here)
To avoid circular project dependencies, I'd recommend using Unity design-time configuration via a configuration file instead of run-time configuration (as you have in your example). Otherwise your Common Library will have to reference the projects that contain all of the types it resolves and those projects, in turn, would be dependent on the Common Library (since that is presumably where you would expose the UnityContainer instance). You may be able to get it to work using run-time configuration, but I have not tried that; I do know that the design-time configuration works as I have done a few projects using a model exactly like this.