Parser Error on all new aspx pages in IIS7 - c#

I have a web site where any new aspx pages throws a "Parser Error". It has existing pages, and I can change the html or the c# code in it, and the change will appear in the web page in the browser.
The error page gives a message of "Could not load type classname". I've tried adding several different pages in Visual Studio, and copying the pages to IIS, so the syntax of the page should be fine.
I;ve also made sure that the "Inherits" attribute has the correct class and the class exists. I'm completely stuck.

Have a look at the Directive at the top of the page. Does it have a CodeBehind attibute? If so change it to CodeFile, and try the page in the browser again.
If that doesn't work, compare the top part of a non-working page and a working page. Would be a little easier if you could post the top parts of the page here.

One thing that popped to mind immediately is to make sure that the target version of the .NET Framework for your web site is the same as the one specified for the application pool in IIS in which the site is running.
Right-click on the web site in Visual Studio and check the "Target framework" setting. Make sure this matches the ".Net Framework version" setting in IIS.

Are you using any usercontrols? Is your project set up as a web Application project or website?
If you are developing a web application project and you copy a new file or add a page without using the add new by right clicking you may have some page files that lack their designer files.
If that is the case then I suggest right clicking any page missing the designer file and click "Convert To Application" Then rebuild your solution

Related

Visual Studio 2019 .NET CORE and React Template Subsite

I am having a hard time getting this template to work as a subsite.
The steps that I took to create the project were:
Launch Visual Studio
Create a new project
Select ASP.NET Core Web Application
Gave the details for where the project should be stored, etc
Create
At this time I am not interested in redux so I just selected the "React.js A project template for creating an ASP.NET core application with React.js"
After that I thought that the steps to make this work at a sub-site would be:
Right-Click and Properties on the Web App Project, on the debug tab I set the App URL to what was there + /mysub, for example: http://localhost:57197/mysub
Inside the Client App Folder I modified package.json and set the "homepage" to "/mysub"
When I debug the application nothing renders in the browser. The browser's console shows that it is getting invalid characters when trying to load resources such as manifest.json, and even bundle.js, which tells me that the client side router is probably intercepting the requests for those files, and when I look at the network tab it looks pretty more obvious that is what is going on. The strange thing is though that tag does appear to be right and thus it is setting the %PUBLIC_URL% environment variable as I would expect, but for some reason it just will not work at this subsite location. I suspect that maybe there is more that I may need to do in Startup.cs, or even appsettings.json but I am not sure what that might be, or if even that is the route to go. Any suggestions would be great.

No .cs files in inherited Web Forms site

First of all, I know ASP.NET MVC, but have very little/no experience with Web Forms. I inherited a site today that is a Web Forms site. Once I got to looking at it, it was quickly apparent that the .cs (code behind) files that go with the .aspx files are missing (or hidden somewhere). I get an error page in the browser when I try to build because the files are missing. The curious thing is that the live site is totally fine...so surely those files exist somewhere?...or maybe you don't need them?...like I said, today is my first day trying to tackle an old Web Forms site.
The files are not present in the local directories nor in Visual Studio. Am I missing something...am I crazy...am I just a newb? I attached some pics.

Why am I getting a 404 error for my code-behind on Azure?

I'm posting and answering my own question in case it helps someone else - I just spend several hours trying to figure out why I was getting a 404 error for the code-behind of an ASPX page. We had converted an existing web site to a web application and published to Azure. The web page worked properly during testing on localhost (IIS-Express), but threw the 404 error when running on Azure.
I noticed that there was no designer file, and after several unsuccessful attempts I gave up and created a new ASPX page, copy/pasted my code, deleted the original, and renamed the new file. Having a designer file didn't solve the issue, but one of the posted answers helped.
When a web site project is converted to a web application project, the "CodeFile" attribute in the Page directive must be changed to "CodeBehind".
<%# Page Language="C#" AutoEventWireup="true" CodeBehind="TestPage.aspx.cs" Inherits="TestPage" %>
Visual Studio does that for you when you convert the project, but it missed this page and a few others. In retrospect, I would have expected a build error or some type of warning from Visual Studio, but maybe the "CodeFile" attribute is valid in a web application.
A 404 error means that the resource cannot be found. Are you trying to load a page with localhost in the url?
Also this could be a relative path issue try opening fiddler or looking in the developer tools (F12) console window to see whether the being sent url is correct. In that it matches the root of your site.

Visual Studio 2010 Disable Designer Code Generation for particular ascx controls

I am currently developing a website for a Berkeley Club in Visual Studio 2010 Prof. Ed. using Asp.net and Dotnetnuke v6. This will be my second time encountering this specific problem/hassle. I created a new control (ascx file) and have been working on it some. I wanted to add the Dotnetnuke htmleditor since its sick so added the required code. Namely...
<%# Register TagPrefix="dnn" TagName="TextEditor" Src="~/controls/TextEditor.ascx"%>
<dnn:TextEditor ID="EmailContent" runat="server" Height="400px" Width="100%" />
I also had to change the ascs.designer.cs file so that instead of reading
protected global::System.Web.UI.UserControl EmailContent;
it read like
protected global::DotNetNuke.UI.UserControls.TextEditor EmailContent;
This makes it use the DNN TextEditor which is what I want. The problem is that whenever VS uses the designer to autogenerate code it overwrites the bottom line with the top line. This means every time I change the ascx file I have to change the designer again. This has gotten annoying, but I have not been able to find a way to fix it. Any ideas on how to disable the VS designer for specific controls or for segments of code in a autogenerated designer file?
Put the EmailContent declaration in the ascx.cs file, and remove it from the ascx.designer.cs file. This will prevent the designer from messing up the type.
This goes to ascx.cs:
protected global::DotNetNuke.UI.UserControls.TextEditor EmailContent;
The problem is that Visual Studio is interpreting the path ~/ to mean the root of your project, instead of the root of the DotNetNuke website (how it will resolve at runtime).
If your module project that you're working on is located in a DotNetNuke site which is hosted in your local IIS, you can setup the project to know where it's actual root is. In the project's properties, go to the Web tab and make sure that it's setup for IIS. The project URL should be the URL to your module (e.g. http://mysite.dnndev.me/DesktopModules/MyModule) and then check the "Override application root URL" checkbox and enter the website's root there (e.g. http://mysite.dnndev.me). This should allow Visual Studio to realize where ~/controls/TextEditor.ascx points, and find the right type.
That said, this works for us about 90% of the time, but we've had some projects where this doesn't work for whatever reason, and then we resort to #mika's answer of moving the declaration from the designer file to the codebehind file.

Parser Error : Could not create type

I have created webservice and published it on local machine. Then I have uploaded it on server.
Now while I tried to access webservice it gives following error :
Parser Error Message: Could not create type 'webservice.myservice'
Source Error:
Line 1: <%# WebService Language="C#" CodeBehind="myservice.asmx.cs" Class="webservice.myservice" %>
I tried This link but unable to solve my problem.
What should I do?
I don't know if this is dragging something up from the dim and distant past, but I had this problem. I fixed it. So I thought I'd to share it.
When you create a web service in Visual Studio (I'm using 2010 but I'd imagine it's the same for others), it creates a file called Service1.asmx
You will be tempted to rename it to MyService.asmx (or whatever).
Then you'll look inside and see the line
public class Service1: System.Web.Services.WebService
which you'll change to
public class MyService: System.Web.Services.WebService
and then when you try running it, you get the error
Could not create type 'MyProject.MyService'
Because it still thinks the class is called Service1.
If you right click the .asmx file and select view markup, you'll see it still says:
<%# WebService Language="C#" CodeBehind="MyService.asmx.cs" Class="MyProject.Service1" %>
change it to
<%# WebService Language="C#" CodeBehind="MyService.asmx.cs" Class="MyProject.MyService" %>
save it, try it.
It worked for me.
I had the same problem and looked for it for a long time!
I tried a lot of things including the following:
Frameword version incorrect
A whole list of things that could be wrong
None of those worked for me. After some searching, testing and cursing, I finally found the problem: The application (webservice) was incorrectly hosted.
Let me explain with a little background:
I had a project containing two solutions: One solution was the website that I made (html, javascript, etc), the other solution contained a folder with the business logic, the database model and the webservices. Obviously the webservices folder contained my .asmx files and code-behind for them.
Project
Data Core
Database Model
Business Logic
Webservices
myWebservice.asmx
Website
I was hosting these in the following way:
My website was hosted as a new site with the website folder as root folder
My webservices I was hosting as an application in my website, with the webservices folder as root
More visually:
IIS 7
My Website => Pointing at the "Website" folder
Webservices Application => Pointing at the "Webservices" folder in the Data Core
This resulted in the following url "http://website/webservices/myWebservice.asmx", which gave me the "Could not create type" error.
Now, after playing around a bit I tried hosting my webservice application starting with the data core as root, instead of the webservice folder.
Visually:
IIS 7
My Website => Pointing at the "Website" folder
Webservices Application => Pointing at the "Data Core" folder.
Obviously using the same url as before would give me a "File not found" error. However, using the following url "http://website/webservices/webservices/myWebservice.asmx",I finally got my working webservices page!
A small url breakdown:
http ://website/ => My website from the "Website" folder
webservices/ => Equivalent to the "Data Core" folder
webservices/ => The "webservices" folder in the "Data Core" folder
myWebservice.asmx => The webservice file in the "webservices" folder, in the "Data Core" folder
I assume that because I was hosting my webservices directly from the "webservices" folder in the Data Core, that the server could not find the compiled DLL of the webservices (which resides in the "bin" folder), since I was hosting at a deeper level.
After changing the configuration and hosting the webservices from the "Data Core" folder, the IIS server could "see" the bin folder and host the webservices succesfully. When using the correct url that is ^_^
I hope this is clear and helps you with you problems!
Another thing that can cause the problem. Is not creating an application for the project through the IIS itself. If the code is already on the server navigate to it in IIS from the left Connections pane. If the web site directory is still a yellow folder icon (and not a globe icon) you need to right-click on it and choose Convert to Application otherwise follow these steps...
Start -> Search For IIS
Open It!!
Right Click on the Default Web Site or the web site you are planning to publish the service to it.
Add application... Enter an Alias ex. "MyWebService" ... Choose the physical path. in my case was C:\inetpub\wwwroot\MyWebService which is my default web site path.
Then when you publish through Visual Studio choose that folder. or just copy your code files to it.
I'm fairly certain this is just a summary of what Glenn said, but I ran into this issue because my application was created from the directory one level too high in the directory structure.
For example, my web service was in SiteProject_1/SiteProject_2/service.asmx
Originally SiteProject_1 was what I converted into the application within IIS. I was able to resolve the issue by removing that application within IIS and instead making SiteProject_2 into the application.
I was having this problem this morning and Google landed me here, but none of these answers worked for me. But I did figure out what was wrong - at least in my case - so I thought I'd share it in case it helps others.
I had a web service that had been working fine for months in a solution with other parts of the application that I work on. Yesterday, I needed to fix something in a release branch, so I opened Visual Studio on a copy of the solution in another directory. Visual Studio decided to be helpful and silently remap all my virtual directories in IIS to where the programs would be in the release folder (if I had bothered to build them, which I hadn't). Now when I tried to hit my web service, IIS was pointing to the release version which had the asmx but no bin folder.
Opening the Web properties tab in my development solution and clicking the Create Virtual Directory remapped it back to the development version and all was good with the world again.

Categories

Resources