Building old-style ASP.net application (with System.Web) - asp.net

I have an old asp.net that I'd like to move from a Windows environment to Linux.
The application has an old Web.config, a bunch of dlls and an App_code folder.
Can you point me in the right direction to getting this working?
What I've tried so far:
dotnet publish -c Release -o /var/www/blah
But this complains:
app_code/Rewriter.cs(3,14): error CS0234: The type or namespace name 'Web' does not exist in the namespace 'System' (are you missing an assembly reference?
I read that System.Web doesn't really exist anymore.
My question is, can I reference some kind of build environment that will build and deploy this old-style application? Or so I need to port all the code?

Migrate any business logic to classes, so you can reuse it. The more code you can move to classes (or even class libraries), the easier it will be. Then create a new ASP.NET core application and rebuild the UI bits.
The hardest part is if you have a lot of spaghetti because you over-utilized the event methods in your code behind files. You may end up with a lot of refactoring, but the idea is to keep it working as is, but with the actual code outside of the ASPX pages. Once your event handlers look more like this
public void THisButton_Click(e as EventArgs)
{
OtherClass.Method();
}
you will find it much easier to migrate to MVC, which is how you will want to design the UI with for ASP.NET Core.
If this is not making sense, let me know, and I can see if I can point you to some information that helps.

Related

issue with .net assembly

I have created some class A.cs whose function is to be used in B.cs then B.cs is called in ASP.net webforms in codebehind. My files A.cs and B.cs is kept in App_Code folder.
The issue is if i call the function of B.cs in asp.net webform codebehind i get error that function is not defind are you missing an assembly? After researching on SO, i found to make class build action to compile. Though it solved the issue, but when i build the app i got error that my assembly is present in root as app_code and assembly.dll both
Then i reverted the process, and got same function not found issue.
I am seriously unable to figure out,How to solve this???
I run into this exact problem before. The way I fixed it is moving all the code files form App_Code folder to a Classes folder (or any folder of your choice) and then compile and fix the compiling errors. After, the error went away.
It sounds like you may have defined the Gal.DB.Service class in both the ASP.NET web app (under App_Code) and in an assembly that the web app references (i.e. Gal.DB.Manager.DLL).
The class can only be defined once.
try clearing the temporary asp.net files, depending on what web server you are using, you'll want to stop, reset or kill it to release the files before deleting them.
It sounds like this is a web app, where asp.net makes its best guess about what needs to be compiled. If this compilation model causes too much trouble, web project might be easier in the long run.

What makes an ASP.NET project an application vs library?

I am inheriting some ASP.NET code (I am an OS guy, not a web dev (yet ;-)). The solution has been re-factored and there are multiple projects (libraries and asp.net sites) in it. Aside from the libraries, there are two asp.net projects (called MAINSITE and SUBSITE). Only MAINSITE is being used as the official site (as an asp.net site), and MAINSITE has a depency on the code in the SUBSITE asp.net site, but doesn't use the site itself. I am trying to figure out how to clean this up and convert SUBSITE into a library.
My quick question is, whenever I debug the MAINSITE (set as default), it runs two asp.net processes: MAINSITE and SUBSITE. And so, at the very least, how can I avoid this? Is there a quick/temporary solution to this?
My detailed question is this:
What makes an asp.net site an asp.net site? For instance, in C the difference between an dll and exe could be defined (superficially anyway) as the presence of a main, and potential export information for the library (among other things, of course). If I were to convert an exe to dll I might:
1. remove the main code
2. make sure the public interface was correct (and exported correctly)
3. convert the makefile to build a dll rather than an exe.
Can someone point me to some similar steps for asp.net to .net lib?
Maybe:
1. get rid of index.aspx
2. get rid of web.config
3. any *.cs files to remove?
4. how do I change the properties?
5. any gotchas?
Thanks so much for your help.
Details: Visual Studio 2008/.NET 3.5
There are many, many components to make an application run as an ASP.Net application. However, in terms of your actual Web Application project, there's really not that much difference between it and generic library code except for the fact that much of your code relies on the existence of the HttpApplication runtime.
Any code that utilizes the System.Web (especially System.Web.UI) is going to be suspect in terms of having this dependency. For example, all the code in page or webcontrol event handlers (Init, Load, PreRender, etc.) relies on the fact that there is an HttpHandler (running inside an HttpApplication) raising these events. If you run the same WebControl out of a library that's not in an ASP.Net project, none of this will ever happen and the control will be useless. However, that exact same library would be quite functional if executed in the context of an ASP.Net process.
It really boils down to what process you're running the library in. In most cases, ASP.Net processes are spawned by IIS, although it is possible to host an ASP.Net process in other types of programs as well.
There isn't a simple 5-step process for converting a web project to a library unfortunately. But as a rule of thumb, webcontrols, .aspx and .ascx codebehind aren't going to convert.
For a more detailed look at what makes code into an ASP.Net program, see Rick Strahl's "A Low level look at ASP.Net".
If you go to "File" > "New" > "New Project..." and then click on the (assuming you're using C#) "Visual C#" in the list on the left, you're given the ability to create a "Class Library" project. You can extract all the relevant code to one of these and then reference in in your "MAINSITE".
You will need to reference it in the "References" section of your MAINSITE project and may need to import your library project using the import keyword.

Compiling/Embedding ASCX templated UserControls for reuse in multiple web applications

I'm onto a real head scratcher here ... and it appears to be one of the more frustrating topics of ASP.NET.
I've got an assembly that implements a-lot of custom Linq stuff, which at it's core has zero web functionality. I have an additional assembly that extends this assembly with web specific behaviour.
The web specific behaviour comes with a couple of user controls marked up inside ASCX templated UserControls.
I'm having trouble putting a nice finish on this assembly so that it is simple to redeploy for use in other applications. Let me run through what I've tried so far:
Copied the ASCX files to the consuming web application using build events; far from ideal and quite a deployment nightmare.
Implemented a custom VirtualPathProvider and embedded the ASCX templates within the assembly as embedded resources. Unfortunately when using the Register directive in the consuming application it creates the designer declaration as a UserControl, where I would require a declaration of the actual control type; unforeseen (typically) and undesirable.
Created a Web Deployment Project to compile the UserControls, but the compiled user controls then become part of another assembly, and no longer descend from the class definitions in my web assembly--the assembly needs to instantiate them dependent on the request context.
So number 1 is just crap, number 2 doesn't give me the type support I desire and number 3 I think I'm about to produce a reasonable solution with:
Lump all non-control classes into the App_Code folder, prepare a factory class that will construct an object of the desired control type using reflection and the expectation that the type being reflected will be present in the deployment output (hopefully guaranteed by the presence of the ClassName attribute in the Control directive).
Theres also always the other option of rewriting the ASCX controls into custom controls, but just don't have the resources to consider it at the moment, and we've got no expertise in doing that, and they work fine as UserControls.
Am I missing something obvious, something maybe much simpler, or is this just purposefully difficult? I've read stories of the ASP.NET compilation process being very unfortunate in it's design on my travels across this topic.
Well I think I've done it ... by being mindful of a few of a few annoying pitfalls with my last approach, I recommend the following when compiling ASCX user controls in a Web Application Project using a Web Deployment Project:
Avoid putting classes in App_Code unless they're standalone or helper classes, ASP.NET treats this as a speshul folder, the meaning of which is lost on me, mayhem, confusion and chaos follows. Code in this folder does get output in the Web Deployment Project, though.
Pay close attention to your assembly names, their root namespaces and deployment output assembly name- you'll get access is denied errors if you have any naming conflicts during the aspnet_merge process.
Ultimately you'll most likely end up deploying 2 assemblies, I tried to create only one but the deployment output was still pointing to type definitions in the source assembly. This isn't a problem if you don't have any other types in your Web Application Project--I have so it was a problem for me. In my case, my final output was:
<Organisation>.<TechnologyName>.Web.DLL - Compiled Web Application Assembly (containing the ASCX templates)
<Organisation>.<TechnologyName>.Web.UI.DLL - ASP.NET Compiled UserControl assembly, created by Web Deployment Project
Clean often, and check that the Web Application Project's bin and obj paths are cleared of any previous junk built when you perhaps hadn't finalised your namespace or assembly naming scheme--the Web Deployment Project will be quite keen to include these, causing a fine mess.
Check your imported namespaces, the ASP.NET compiler likes to refer to the Import directive in the ASCX template, and it also considers imported namespaces present in web.config's <configuration><system.web><pages><namespaces> element, tweak if you get unknown definitions appearing during the deployment process.
Have some patience spare, it's quite tricky! But you do get some nice re distributable UserControls at the end of it!
Phew!

System.IO.FileNotFoundException when loading web service

I've a simple, if not primitive, C++/CLI .NET 2.0 class library. It is used in order to wrap some C++ legacy code for the Web Service. The following facts appear to be true:
Primitive C# test program calls class library and it works.
If class library does not refer to any modules of our code base, it works as well as part of the web service. That is, I load the web service and invoke the methods and receive proper response.
The same moment I replace the copied and pasted code by the calls from our code base libraries, the Web Service stops to load. I get System.IO.FileNotFoundException message.
The problem: I cannot find any place where the file name that couldn't be found is written.
I googled it and gave some permissions to some ASP.NET user on my computer. I copied all the DLLs of our libraries into the same directory where web service is installed. I searched in IIS logs, event logs, etc - no where could I find the name of the module that prevents the web service from coming up.
Any help on the matter would be greatly appreciated.
Boris
Make sure all the dependent DLLs are in the path (Path meaning not the directory where your assembly is, because ASP.net copies your assembly away into a temporary folder, but rather a directory that's included in the System path environment variable).
What calls are you replacing? Could it be the original code gracefully handles missing files (which may not even be important) and yours does not?
Add same rights to the iusr-account that you did to the asp.net-account.

Casting error in ASP.NET

I have a class declared in the App_Code folder. The class contains a public shared method that returns a type Portfolio.
When I try to call this method to initialize an object of type Portfolio in one of the ASCX controls, i get a "Value of type Jaguar.Portfolio cannot be converted to Jaguar.Portfolio" message.
This is a "Website" project. I have tried using CType and DirectCast and I still get the same compilation error when I try to build the site.
I am using the line of code listed below in the code behind file of the ascx control
Dim pObjSvc As Jaguar.Portfolio = ClassName.GetPortfolio
Do you have a webpage or a user control also called Portfolio? You may have a name space collision where it's confused between which Portfolio object to use. If this is the case, you'll need to change the name of the Class/Module or the control's or page's code behind class and you should be all set.
There seems to be someone else with the same problem out there:
ASP Net - value of type "MyNamespace.MyClassName" cannot be converted to "MyNamespace.MyClassName"
I have a ASP.Net application that uses
assemblies from several other
solutions. When testing the
applications on my machine I build all
the referenced assemblies using nmake.
The latest assemblies get placed in a
common directory that is referenced by
my ASP.NET app.
Occasionally I receive the following
error: value of type
"MyNamespace.MyClassName" cannot be
converted to "MyNamespace.MyClassName"
(there are a lot of these for
different classes) when doing a debug
build. I have tried the following with
no luck:
Build the ASP.Net application Rebuild
the ASP.Net application Close VS and
build the ASP.Net application Close
VS.Net as rebuild the asp.Net
application IISreset and build/rebuild
the application
It seems the only thing that works is
if I run nmake to build all my referenced assemblies, I can then
build the ASP.Net application.
Any ideas as to what causes this? Is
there an easier way to fix it?
Sadly, the author of the question did non find a definitive answer. But perhaps it contains a hint which could be helpful to find the solution.
UPDATE: I'm not sure if that is even possible in a ASP.NET website, but maybe you accidentally added a reference to a (temporary) assemmbly of the project itself? That would explain the error. Try also to remove the contents of bin and obj folder.
Just a debugging tip:
Try to rename the Portfolio class and recompile. Maybe there is an old assembly somewhere or some other code in .vb your files which contains a class with the same name?
I have seen situations similar to this when an aspx page was created with the same name as a business object class. Do you have some some aspx page with a code-behind class of Portfolio as well?

Resources