We Keep Coding

Complex Configuration Class asp.net

I have a complex class for configuration, which holds all the configuration data, and I'm reading this class in a separate class that exists in the business class library. In my web project, I am reading this in a pagebase class - which all my aspx pages inherit. I have the class as a property in pagebase, and I can access it in my aspx pages fine. But how do I access this in the usercontrols? Is there a global way to keep this class in memory (I can't have it as static, because its different per user) and I'd rather not use sessions. I was thinking there is a way to have it as part of a global properties somewhere, so I can always use it anywhere in the web project.

If its on all your pages you can just cast the page object to your base page and access the property.
inside a usercontrol.
((MyBasePage)this.Page).MyConfigObject

You can put it in HttpContext.Current.Items dictionary around page creation time. It will be avaialbe during lifetime of that request.
Note: Tey to find other ways to achieve whatever you want to achieve without global/per-request state...

How to make one ASP.NET MVC site "derive" from another

My question is similar to "ASP.NET 2 projects to share same files", but with an ASP.NET MVC slant.
Basically, we have two sites, one being based mostly on the other (roughly 90% views, controllers, images, in the second are identical to the first). However, in some cases, the views may be different, or a controller in the second site may be different to the first.
Are there any simple ways of achieving this in ASP.NET MVC?
So far, we've looked at using linked files to have two totally seperate projects where the second project shares the files it needs from the first.
One problem with this approach is that most pages in the second project don't literally exist in the virtual directory, it makes debugging a pain - you have to publish in order to generate the files so you can debug.
Does anyone have any better approaches, or ways this approach can be simplified?

This article might help: http://dotnetslackers.com/articles/aspnet/storing-asp-net-mvc-controllers-views-in-separate-assemblies.aspx
Essentially, it involves creating your own WebFormViewEngine which tells MVC where to look for the Views.

If they are 90% the same and you want to keep them in sync as functionality evolves I would consider making them into a single web application and using the host header to differentiate and to change the images/links/text/functionality/etc. between the two sites.
You can do this in your BaseController: look at the host header and create a Brand object that every page and view has access to, just like it might have aUser object. That Brand object can include the name of the site, the canonical Url for the site, the location of the image directory for that brand, boolean values to turn certain features on or off, ...
Now in a Controller you can just ask if (Brand.SupportsPageX) {...} to decide what to show next. And if you make the brand object part of your base view model or put it in the view collection you can have views that use the brand's name, image directory, ... to customize how they look.

Put as much as possible into a shared non-UI library project. I do that on every project that I work on this, increased testability, shared code with Windows Services, and a host of other reasons.
I've found that if you're aggressive with this then quite often over two-thirds of the project would be in the non-UI shared library.
After doing this, you can take things a step further and create a second library with some shared MVC/UI elements.
Depending on your opinion of it, RenderAction may help a bit here. As you know, RenderAction will allow you to group up those controller/view components and pass in variable arguments at runtime.

A project I'm working on currently has a similar requirement and we have started looking at using portable areas. I personally haven't delved very deeply into them at the moment, but it may be worth you taking a look.

I've been working with areas to create multiple websites that I can host with one hosting account. I would think you could use a similar approach. By implementing the common functionality in the base project, it will be available to each area. You can also override any of the base views or controllers by implementing them in the area. It may require some tweaking of the ViewEngine and Routing but I think it could be done.

Can I expose only a portion of one .NET DLL's public classes via a different "API" DLL?

I am designing a WPF application that uses a DLL with maybe 40 public classes. I need these to be public for a variety of reasons including ease of data binding and obfuscation. I would like to allow other people to use only a portion of these classes as an API for my software.
I thought I would create the main library (core.dll) and an API library (coreAPI.dll) with the API DLL to be referenced in a new project. Is there a way to allow coreAPI.dll to expose only a few of the classes that exist in core.dll? It's not so much a security issue as I primarily want to simply hide some of the unwanted classes from the Visual Studio Intellisense.
Again, internal classes for the ones I want to hide is not really an option because I need to data bind some of these classes in WPF and for that, they must be public. Are there any other ways of doing this?

As Damien already mentioned, if the only thing you'd like to do is to hide from Intellisense you can add the following attribute to your hidden classes:
[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]

If the primary issue is Intellisense, then moving these classes into a separate namespace would surely do the trick?
Of course, you could split the classes into two separate assemblies. You may have some issues there with having to expose more classes than you want (because they now live in separate assemblies), which might be resolvable using the InternalsVisibleTo attribute

Accessing a Class that is NOT declared in App_Code in ASP.NET

I sometimes define Business Logic classes to "help" my ASPX code-behind classes. It makes the most sense to me to include them both in the code-behind file since they work together. However, I'd occasionally like to access the Business Logic classes from higher level classes defined in App_Code but they aren't automatically accessible outside of the file.
Thus, the question: it is easy to access classes defined in App_Code but how do I access classes defined elsewhere?
UPDATE: One other thing, the ASPX page class and the App_Code class are in the same namespace - that isn't the issue.
NOTE: I have taken the advice of those who have responded (thanks guys) and am refactoring to make class access easier. However, I don't think the question is actually answered yet (in the case of an ASP.NET Website project). I don't need the answer any more but, if someone could clarify what makes classes visible when they are outside of App_Code, it may well help someone else (or even me, down the road).

Make sure you place your classes in a sensible namespace.
Place 'using' keyword in code behind files you would like to access them.
Or <%# import if you are using them in inline code.
Put the dll that contains your classes in the /bin folder.
TBH I prefer to keep the separate library project in the same solution and have project reference in the Web probject. VS handles building and placing the dll for you.

Some time while you create or add any file it has been create as the content file while it has to be compile file.
Please follow the process how to resolve this issue.
1) Right click on your class file in App_Code folder.
2) Click on properties.
3) Change Build Action from "" to Compile
4) Rebuild your Application.
This will work definitely
Tushar Tyagi

I assume you mean you are defining a separate class inside the codebehind .cs file? What access modifiers are you giving them?
As above though, I'd generally have a separate project in the solution for this kind of thing (usually in a different namespace like MyApp.Web and MyApp.), and just reference it from there.

You can also just create a standard folder in your project to access classes, and move them there, but you have to do some additional things to make it accessible to your project:
Ensure you don't name the folder any of the reserved terms (i.e. call it "AppCode", instead of "App_Code") if you are running into issues with the "App_Code" folder, after going through the rest of these bullets.
The classes should all have the same namespace as your code-behind.
Ensure the classes are made public, with public methods, if they are being called from other classes.
Include "using MyClass;" statements at the top of the code-behind/class files.
Make sure the class' Build Action property is set to Compile.

You can not access a class from another class in same code behind file as .net dsnt support multiple inheritance. but you can create you business logic class as inner class in main class and make its all functions public so that they can be call in main class.

C#: Partial Classes & Web Services: Separating form and functionality

I am dabbling in the world of web services and I've been making a simple web service which mimics mathematical operations. Firstly it was simple, passing in two integers and then a binary operator would be applied to these (plus, minus etc) depending on the method called.
Then I decided to make things a little more complex and started passing objects around, but then I discovered that a web service only exposes the data side of the class and not the functional side.
I was told that a good way to deal with this is to make the class on the service side a partial class (this side of the class encapsulating form) and on the client side have another partial class (where this side of the class encapsulates functionality). This seems like an elegant way of doing things..
So, I have set up two classes as described above, but it doesn't seem to be working as I was told.
Is what I am attempting possible? If so, where am I going wrong?

Partial classes are really a tool to separate auto-generated code from developer code.
A good example is the windows forms designer in VS, or the new DBML Linq DataContext generated code.
There's also an argument for using them with VSS style source control providers where only one user can edit a file at any one time.
It's not a good idea to use them for logical separation of functionality - the division only exists pre-compilation. As soon as you compile you get just the one class, but not one that it's easy to debug or track operations inside.
What you've described sounds like a really good situation for using WCF contracts. In that case both client and server would share an Interface (or Interfaces).
Your complex code would go there and could be unit tested separately - i.e. outside of your connected application. Then when bugs are found you can eliminate code issues quickly and move to investigating connection related ones instead.

Not with partial classes. A partial class is a syntax construct that gives you the ability to have different parts of the class in different source files. However, all parts of the partial class are ultimately compiled into the same binary.
You could use extension methods to add functionality to your class that represents the data contract.
You could also try implementing the class in a shared assembly and use the svcutil.exe /reference to get it imported in the client proxy instead of having a brand new declaration in the web service namespace.

As Franci said, it simply allows you to put separate parts of the same class into different files.
How you should structure things instead really depends on what you are doing. If I were you I would likely have a rather plain data carrying class and a consumer which could be used to process that data.
The use of a shared assembly is also a good idea. However, if you really wanted to be able to send the code from the server to the client CSharpCodeProvider would work.

(This thread's probably dead but...) I was thinking of doing something similar, but with the functionality on the (in my case) Windows Service.
Both the client program and the Windows service need access to the data, but only the service needs to actually do anything with the data; they are both including in a dll that holds a partial class containing contracted data members, however I get an error saying this partial class conflicts with the partial class on my service even though they are both in the same namespace and at the moment, the server's partial class is empty.