IIS 6 Virtual Directory created without the asp.net application extensions - c#

I have a configuration page that needs to create a virtual directory under a new virtual application. The method for creating this directory is distinct for the version of IIS, with the IIS 7 installs using the newer management controls. The IIS 7 installs create the virtual directory and add the expected asp.net application extensions. The following code, used for IIS 6, does create the virtual directory, however it does not add the asp.net application extensions as you can see in the image below. How do I modify my code to ensure the expected asp.net application extensions get added?
private void AddDirIis6(DirectoryEntry entry)
{
var child = entry.Children.Add("EditorControls", "IIsWebVirtualDir");
child.Properties["Path"][0] = "directory\EditorControls");
child.CommitChanges();
entry.CommitChanges();
}

It looks like the script mappings are missing for your site. You can either run
aspnet_regiis -s W3SVC/1/ROOT/SampleApp1
with your application specified for the last parameter instead of the sample one or
aspnet_regiis -i
Be aware that -i installs the script maps for ALL sites on IIS.
You will need to execute the aspnet_regiis for the correct version of the framework you are using. Instructions to do this are in the instructions for the aspnet_regiis tool:
http://msdn.microsoft.com/en-us/library/k6h9cz8h(v=vs.100).aspx

Related

Asp.net core keep using the expired certificate

Recently, my localhost certificate is expired, I have gone to "sertmgr.msc" remove all localhost certificate and restart the VS and add a new localhost certificate to windows.
But when am I running my application again, still use the old expired certificate not the new one, does anyone know how to fix that?
I have already run the command show below.
dotnet dev-certs https --clean
dotnet dev-certs https --trust
Expired Cert
Cert In Cert Manage
I managed to hack my way around this issue:
Before you do anything, clean the old certificate and generate a new trusted one.
dotnet dev-certs https --clean
dotnet dev-certs https --trust
And if the process above fails, manually remove the certificates before retrying the clean/trust commands.
Get the User Secrets ID of the Web Application you're having trouble with. Search for UserSecrets.UserSecretsIdAttribute(" in your project folder and take the GUID.
Go to %APPDATA%\Microsoft\UserSecrets and open the folder containing the GUID of the problematic project you are struggling with and leave it open.
Create a new Asp .Net Core project, get its secrets GUID, go to the corresponding secret folder (%APPDATA%\Microsoft\UserSecrets\GUID), and open the file secrets.json. You should see something like this
{
"Kestrel:Certificates:Development:Password": "8353f2ec-3cc0-4052-9776-9585b6abd346"
}
Copy that setting from the newly created project secrets.json and use it to override the development password on the secrets.json of the broken project
This way, I've managed to get my old project to use the newly generated certificate. It is hacky, but it works
Based on Pedro's answer,
I used:
dotnet dev-certs https --clean
dotnet dev-certs https --trust
to clean/replace the old certs.
Then I went to:
%APPDATA%\Microsoft\UserSecrets
And deleted all the folders found there.
Now my application runs without complaining.
Creating a new .net core 6 application and running it didn't create a new folder, so I don't know if it's no-longer required.
I assume you're using IIS Express to host your application. If so, it sounds like you're missing linking the certificate to your application(s) as described in this blog post:
Go to C:\Program Files (x86)\IIS Express and run the following from the command line, entering the proper port number and the new certificate thumbprint:
IisExpressAdminCmd.exe setupsslUrl -url:https://localhost:PORT/ -CertHash:THUMB
I want to provide some context about Pedro's answer on Windows.
Thanks to this article and some testing, I found out that the password specified by Kestrel:Certificates:Development:Password setting applies to a project dedicated certificate found in %APPDATA%\ASP.NET\Https.
Answer: When you delete either the password setting or the project certificate, Kestrel starts working as expected, looking for a proper certificate installed with dotnet dev-certs command. I think the most convenient is to delete all project certificates from %APPDATA%\ASP.NET\Https folder.
This seems to be a Visual Studio problem when the project was created. However, I could not reproduce it with my current version of Visual Studio 2019.
In conclusion, the problem is not about the dotnet dev-certs command, but rather about hidden logic on how Visual Studio creates the project and how Kestrel handles certificates.
I had the same problem with different types of projects:
ASP.NET Core with Angular template created with VS Code.
ASP.NET Core Web API created with Visual Studio.
When the problem comes with the ASP.NET Core with Angular template on Windows, you can try:
Stop the application.
Open the File Explorer.
Paste %APPDATA%\ASP.NET\https into the address bar and press enter.
It will navigate automatically to C:\Users\[your_user]\AppData\Roaming\ASP.NET\Https
Delete the your_npm_package_name.pem and your_npm_package_name.key files.
your_npm_package_name: Is the name property value of the package.json file of your Angular client app.
Open MMC (Start > Run > MMC). Open the Certificates Snap-in (File > Add/Remove Snap-in).
Select My Current Account when prompted.
Under Certificates - Current User select the Personal\Certificates folder.
Locate and select the certificate for localhost domain and with the Friendly Name "ASP.NET Core HTTPS development certificate".
Delete the localhost certificate.
Repeat the localhost certificate deletion process for al localhost certificate with the Friendly Name "ASP.NET Core HTTPS development certificate" under the Personal\Certificates folder and the Trusted Root Certification Authorities\Certificates folder too.
Start your application again.
Your application's pem and key files will be automatically regenerated.
This solution is also valid for other advanced templates like Jason Taylor's Clean Architecture Solution Template.
When the problem comes with a ASP.NET Core Web API project created with Visual Studio and enabling Docker (not always).
After trying all the alternatives of this question and using the Generate self-signed certificates with the .NET CLI and Enforce HTTPS in ASP.NET Core guides from Microsoft, I found that my expired certificate was located in the C:\Users[your_user]\AppData\Roaming\ASP.NET\Https folder with the name my_api_assembly_name.pfx.
How did I regenerate my certificate?
Stop the application.
Open the File Explorer.
Paste %APPDATA%\ASP.NET\https into the address bar and press enter.
It will navigate automatically to C:\Users\[your_user]\AppData\Roaming\ASP.NET\Https
Delete the your_my_api_assembly_name.pfx.
Open MMC (Start > Run > MMC). Open the Certificates Snap-in (File > Add/Remove Snap-in).
Select My Current Account when prompted.
Under Certificates - Current User select the Personal\Certificates folder.
Locate and select the certificate for localhost domain and with the Friendly Name "ASP.NET Core HTTPS development certificate".
Delete the localhost certificate.
Repeat the localhost certificate deletion process for al localhost certificate with the Friendly Name "ASP.NET Core HTTPS development certificate" under the Personal\Certificates folder and the Trusted Root Certification Authorities\Certificates folder too.
Open your Windows Terminal as administrator.
Run dotnet dev-certs https -ep $env:USERPROFILE\AppData\Roaming\ASP.NET\Https\your_api_assembly_name.pfx -p your_user_secrets_id:
Change your_my_api_assembly_name with your own assembly name.
How to retrieve your_user_secrets_id?
Open your_project.csproj with a text editor (or double-click on the project in Visual Studio Solution Explorer) and look for a node called UserSecretsId. Inside this node there is your your_user_secrets_id.
Otherwise, if you don't have the UserSecretsId node in your project file:
Open the File Explorer.
Paste %APPDATA%\Microsoft\UserSecrets into the address bar and press enter.
It will navigate automatically to C:\Users\[your_user]\AppData\Roaming\Microsoft\Secrets
Open the folder called as the GUID of your project (you can get yours inside your your_solution.sln file).
Open the secrets.json file and find a property called Kestrel:Certificates:Development:Password. The value of this property is your your_user_secrets_id.
Your application's pfx file will be automatically regenerated.
Run dotnet dev-certs https --trust.
You will be prompted to install a new certificate for localhost.
Click Yes.
Start your application again.

Calling Web Service in a Windows Service

I've used a simple windows service to make a method work in specific time and it works fine. Following that I've already tried:
protected override void OnStart(string[] args)
{
this.WriteToFile("Simple Service started {0}");
this.ScheduleService();
}
protected override void OnStop()
{
this.WriteToFile("Simple Service stopped {0}");
this.Schedular.Dispose();
}
private Timer Schedular;
public void ScheduleService()
{
try
{
Schedular = new Timer(new TimerCallback(SchedularCallback));
string mode = ConfigurationManager.AppSettings["Mode"].ToUpper();
this.WriteToFile("Simple Service Mode: " + mode + " {0}");
//Rest of the code here
}
catch(Exception ex)
{
WriteToFile("Simple Service Error on: {0} " + ex.Message + ex.StackTrace);
//Stop the Windows Service.
using (System.ServiceProcess.ServiceController serviceController = new System.ServiceProcess.ServiceController("SimpleService"))
{
serviceController.Stop();
}
}
}
This is done in a simple windows application. So what I am trying to do is to call a web service (A specific method to operate in a specific time) in a windows service. The application I am building is web-based and am little bit confused how would I integrate the windows service into it? Do I need any alternatives or any suggestions would be appreciated.
Note: What I would like to know is it required to create another project for windows service in the web application or any other way to implement?
To call a web service from a Windows Service application, you would first generate a DLL from that web service, then instantiate its namespace. Assuming you have the code for that web service and/or know its namespace, you can perform these commands to do this:
Perform these lines on a command line:
cd C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
wsdl /l:CS /protocol:SOAP %svc%?WSDL
where %svc% is the URL for your web service, i.e. http://localhost:777/MyWebService.asmx
If the code is in VB instead of C#, change /l:CS to /l:VB.
This will output a proxy class file that can be converted to a DLL.
Move the MyWebService.cs file from C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools to the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ directory.
Run these two commands on the command line:
cd C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
csc /t:library %name%.cs /reference:System.Web.Services.dll /optimize
where %name% is the name of the class (without the .cs, since the command will append this). In our case, we'd use MyWebService. (Change .cs to .vb for a VB class.)
Navigate to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 via Windows Explorer. You should see a DLL created in that folder with the name of the class (MyWebService.dll). Copy this file to the bin folder of your Service project. You will need to set the bin folder to be included in your project, and right-click the folder to Add > Existing Item. Select the DLL. Once imported, select the DLL and change its properties to:
Build Action: Content
Copy to Output Directory: Copy if newer (or Copy always, as you prefer)
Right-click References > Add References. Navigate to the DLL in the bin folder for your web service.
Right-click References > Add Service References. Assuming your web service is running, take its full URL (i.e. http://localhost:777/MyWebService.asmx) and put that on the Address line. In the Namespace textbox, give it something more meaningful than ServiceReference1, but it should not be the same as MyWebService (the name/namespace of the ASMX file). Perhaps MWS.
Instantiate your web service in your Windows Service:
MWS.MyWebServiceSoapClient webService = new MWS.MyWebServiceSoapClient();
webService.Open();
string someDataYouWant = webService.SomeMethodToGetData();
webService.Close();
Or you can probably do:
MyWebService webService = new MyWebService();
string someDataYouWant = webService.SomeMethodToGetData();
webService.Dispose();
In answer to your query on my comment;
Another approach is to use an IIS Auto-Start website contaning your Windows Service logic. The IIS Auto-start is supierior to using a Windows Service as it contains all the IIS application hosting logic including auto-restart, and aggressive resource management. A poorly written Windows Service can take down a Server but it takes a lot for an ASP.net IIS hosted application to take down its host (its almost impossible).
Your Auto-Start website need not be visibile to the outside world - it just needs to have an internal timer that keeps it alive when it starts up. Note that the web application might be started and stopped by IIS for various reasons; but the outcome is that it will be running whenever your other web service application is running. The internal timer can wait for a specific time to execute the logic you need to call your second web service.
The key thing to remember is that a Windows Service is designed to be an application that is hosted by Windows and is continually running. An IIS application is designed to be run by Windows but runs only when called. The IIS Auto-Start website concept allows you to provide a "continually running" website but hosted by the robust IIS application hosting components, instead of it running directly as an OS process.
Generally people dont do this because either they dont know about it, or want to avoid needing the IIS infrastructure to run "Windows Service" type applications, but in your case you have already paid the cost of using IIS to host your second web service, so you may as well make full use of IIS (and avoid the second technology stack and deployment headaches of Windows Service deployment).
So I suggest using an IIS Auto Start in preference to a Windows Service in your situation because;
You only need to use on tech stack in your solution, which was what your OP was asking about
IIS carries out active resource management on all its applications, terminating, restarting as neccessary if they become non-functional. Windows Services do not have that capability.
Your IIS based service code is XCOPY deployable with no administrator access credentials on the target machine.
Your IIS service is hot upgradeable without needing OS level administrator rights - IIS handles the stopping and restarting on upgrade without you needing to do anything.

Elastic Beanstalk not running any commands when deploying asp.net using "Publish to AWS" Visual Studio command

I just registered at AWS services (micro, free) and trying to deploy asp.net mvc 4 application.
Everything is working fine, web application deployed and running (the web part, database, etc), but when i am trying to write to filesystem (for example, when i`m saving a file), i'm gettig an exception
System.UnauthorizedAccessException: Access to the path
'C:\inetpub\wwwroot.logs\xxx.log
The folder "C:\inetpub\wwwroot\.logs" exists.
I tried to grant a permission to folder to DefaultAppPool using commands.
I have following web project structure:
WebHost
.ebextensions
aws.config
aws.cofig has following content:
container_commands:
01-logscreate:
command: "mkdir C:\inetpub\wwwroot\.logs > create-logs.log"
cwd: "C:/inetpub/wwwroot/.ebextensions"
01-logspermission:
command: "icacls \"C:/inetpub/wwwroot/.logs\" /grant DefaultAppPool:(OI) (CI) > p-logs.log"
cwd: "C:/inetpub/wwwroot/.ebextensions"
When i accessing the file, i resolving the full path using
HostingEnvironment.MapPath("~/.logs/xxx.log")
But when i trying to write to this file, a get an exception.
Relative path of '.ebextensions' in deployment package is
Content\D_C.git\udsmonitoring.app\WebHost\obj\Debug\Package\PackageTmp\.ebextensions
Thanx in advance
The app pool that gets deployed runs with limited permissions. It doesn't have access to write to that directory.
Further, you really shouldn't need to be writing logs to the instance file system itself. These instances are transient. If you need a logging solution, consider using CloudWatch or LogEntries. Both probably fit into your existing code base with only a config file change required. In general, if what you're doing ends up with you needing to remote into the EC2 instance to do or see something, consider taking an alternate approach.
Finally, if you really do have a need to write to that directory from within the context of your app, you can add a command in your ebextensions that uses appcmd to set the app pool identity to one with greater privileges...or have a command that sets the directory permissions explicitly.

Hosting WCF service in an existing ASP.Net , Deployment Issue

I am trying to use an already existing ASP.net web application to host a WCF service, so I tried the following steps,
1- In Visual Studio 2010, I created web application through the Web > ASP.net Web Application template, named WebApp.
2- Added new WCF Service through Add > New Item ... > WCF Service , named MyServ.
3- Modified the DoWork() method in MyServ.svc as follows,
From
public void DoWork()
{
}
To
public string DoWork()
{
return "hello";
}
and consequently I modified IMyServ.cs to match the new signature.
4- When I run the application on development server and visit http://localhost:1399/MyServ.svc , the service runs fine.
5- So I create a publish for this application, to prepare it to be hosted on the IIS.
6- In the IIS, I create a new website named WebAppSite and is given the port 111, so now when I visit http://localhost:111/ , I am directed for the published WebApp site default page, which is fine and shows that the aspx part of the application is working fine on the IIS.
7- So I try to visit http://localhost:111/MyServ.svc to check if the service is successfully deployed, but I get this message,
HTTP Error 404.3 - Not Found
The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map.
Any idea where the problem is?
you need to register the .svc mime type in your IIS
run "\%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe -i"
Here is a full guide, please apply all steps:
Add “.svc” extension and MIME Type as “application/octet-stream” to IIS Mime Type in Features View.
Register Asp.net by running aspnet_regiis.exe -i command from VS 2010 command prompt (Run as admin).
Right click cmd, run as admin, go to “C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation” folder and run : ServiceModelReg.exe -i
If you did some changes in your IIS, you may need to go to handler mappings, right click on the static file and select "Revert to Parent".

connectionString encryption

I'm trying to encrypt the connection strings in my web.config. I'm following the instructions from Walkthrough: Creating and Exporting an RSA Key Container. However, when I get to the part with the command:
aspnet_regiis -pe "connectionStrings" -app "/MyApplication" -prov "MyProvider"
it keeps complaining:
"The configuration for the virtual path '/MyApplication' and site 'Default Web Site' cannot be opened
Failed to map the path '/myapplication'
Failed!
I'm fairly sure I've followed the instructions correctly. I created the project named 'MyApplication' directly in the 'C:' root.
Any ideas? Perhaps I should be following a different set of instructions?
Thanks for your answers. Turned out I needed to run the command prompt as "Administrator"
Did you add the MyApplication folder as a virtual directory in IIS under the default web site? That seems to be what it's looking for, not a folder path...
According to this MSDN post, you can use -site to define the site to target. An excerpt from that site:
Use the –app option to identify the application for which the
Web.config file will be encrypted and the -site option to identify
which Web site the application is a part of. The Web site is
identified using the site number from the Internet Information
Services (IIS) metabase. You can retrieve the site number from the
INSTANCE_META_PATH server variable in the ServerVariables collection.
For example, when IIS is installed, a Web site named "Default Web
Site" is created as site 1. In pages served from that site, the
INSTANCE_META_PATH server variable returns "/LM/W3SVC/1". If you do
not specify a -site option, site 1 is used.
/MyApplication is a virtual path and the message seems to indicate that path is not available i.e. there is no http://localhost/MyApplication. Did you forget to create virtual directory for your app in IIS?

Categories

Resources