I have a asp.net project, and wrote a web installer.
The setup exe/msi copies that project in directory chosen by the installing user, and creates an application for it.
How can I get the path my asp.net application got installed to (in the installer)?
I want to write the physical path of my ASP.net application into the registry, because a windows service needs to watch a directory of this web project, and it can't do that, unless it knows where the web project was installed to.
Does the Webinstaller project by any chance write this value into the registry automatically ?
It is possible:
Right-click on the setup project, and choose View->Registry from the context menu.
Right-click on HKEY_Local_Machine, add a new key, call it Software.
Right click on Software, add a new key, call it "MyCompanyName".
Right click on MyCompanyName, from the context-menu, choose new->String
call it installation folder.
Left click on the installationFolder key, and set property value to [TARGETDIR]
Add an additional string key, call it version and give it the value [ProductVersion]
including the []
On x64, you'll find your registry key in regedit under
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\YourCompany]
But programmatically, you can read it normally, from normal projects and web projects, with:
My.Computer.Registry.GetValue("HKEY_CURRENT_USER\Software\YourCompanyName", "Installation Folder", Nothing)
Unfortunately no; IIS uses means other than the registry to store its configuration.
For IIS4, IIS5 and IIS6, you'll need to take a look through the IIS Metabase. This is an XML file in your Windows folder under system32\inetsrv\Metabase.xml; it's XML, so you should be able to read it directly to find the information you need.
IIS7 doesn't use the Metabase any more; instead, see here for details of the managed API to the IIS configuration.
So you may find it best to rework your application to look in either of these places for the directory information that you need.
Related
Our company ships an MVC based product (targeting v4.5) which has stopped working on a customer site for what appear to be environmental issues - a build which worked with no problems once upon a time now gives a 403.14 - The Web server is configured to not list the contents of this directory.
.
What I think is happening...
The user accesses http://server/AppName
Because it's an MVC app, the default route (Reports/Index) should be used.
Instead IIS is looking for a default document...
... and, not finding one, it assumes the user wants to list the contents of the directory...
...which is not enabled so it throws a 403.14.
.
What I've tried so far...
Accessing the route directly.. results in 404 error. So I'm pretty
sure IIS doesn't realise it should use routing.
Use aspnet_regiis to register ASP.Net with IIS. This was done from the Framework64 folder since...
OS is 64 bit - Windows Server 2008 (Standard without Hyper-V)
IIS is 64 bit - though Enable 32-Bit Applications is true
Checked AppPool is targeting v4 of the framework - it is.
Changed AppPool mode to Classic - was pretty sure it should be integrated but was worth ruling it out. It is now back to Integrated
Confirmed RunAllManagedModulesForAllRequests is set to true in the web.config.
Checked permission conditions defined in <system.webServer> section of web.config are met - they are.
Created the simplest of MVC applications and deployed it - same problem.
Running the command shell as Administrator unregistered ASP.Net using aspnet_regiis -ua and re-registered using aspnet_regiis -enable -i. We hit a couple of permission problems - and the Temporary ASP.NET Files directory was missing but once they were address we were back to the same error.
Added a simple default.htm - when present, this is served in response to the http://server/AppName request.
I'm clean out of ideas and all google hits suggest some combination of the above - or enabling directory browsing (which I think is just a symptom rather than the root cause).
Also, not sure if it's relevant but the amount of configurable elements available for the application in IIS seems a bit below what I would have expected...
Have you Checked the user the application pool process is running under? I think Your site needs to run with permissions to execute the .net libraries and I've seen this just change for seemingly no reason (probably related to an overzealous update to the system).
You can try with the Enabling directory browsing .
assuming you are under Windows Server 2012 or Windows Server 2012 R2
On the taskbar, click Server Manager.
In Server Manager, click the Manage menu, and then click Add Roles
and Features.
In the Add Roles and Features wizard, click Next. Select the
installation type and click Next. Select the destination server and
click Next.
On the Server Roles page, expand Web Server (IIS), expand Web
Server, expand Common HTTP Features, and then select Directory
Browsing. Click Next.
On the Select features page, click Next. On the Confirm installation
selections page, click Install. On the Results page, click Close.
if you using the Windows PC try this in your command prompt as follows:
go to C:\Program Files\IIS Express
then press Enter:appcmd set config
/section:system.webServer/directoryBrowse /enabled
Maybe this is your case https://forums.iis.net/t/1157304.aspx
SQL Server Reporting Services creates a folder called Reports by
default if you install it on IIS. If you install SQL 2008 then
Reporting Services doesn't need to use IIS and instead will try to
reserve the URL with the HTTP.Sys service.
I believe this is the cause of the conflict you are seeing. What you
could try is changing the URL that Reporting Services uses via the SQL
Server Configuration Wizard.
Also I found that
Report Manager of SQL Server can use reports path http://<server name>/reports
Configure a Native Mode Report Server for Local Administration (SSRS)
I think the problem is IIS features that are not installed yet. I have met this kind of problem frequently in Windows Pro. Make sure to turn on every feature under Internet Information Service -> World Wide Services because by default IIS is configured to use WebForms. So there might be some features that not installed yet to use MVC, especially ISAPI filters. In my case, that was the solution. I hope it helps.
Something similar i encountered using VS 2017 & ASP.NET MVC.
Was working on the project for long with no problems at all but suddenly the routing started misbehaving & stopped working.
So I changed the Port in Project Properties Page & it started working.
I really don't know what is the relation between a port & MVC routing modules. Someone else can enlighten if at all this helps.
I had the same problem and I just created an application pool out of the Default Web Site in IIS and stoped the default web site. With that difference you will not have the application pool's path
I know it's been a long time since this question but i've had the same problema recently. I've tried every single configuration, just like #amcdermott did, but the only action that solve the problem was reinstalling .NET Framework.
My app was built under .NET Framework 4.5.2. The application server had the version 4.6.1 and 4.5.2 installed. So, i uninstalled all framework versions and installed the one that i needed.
Please, make sure that no other applications use superior versions of .NET Framework if you going to try this solution.
Here are some quote I find on Microsoft official site which I think may help:
For site administrators
This problem occurs because the Web site does not have the Directory Browsing feature enabled, and the default document is not configured. To resolve this problem, use one of the following methods:
Method 1: Enable the Directory Browsing feature in IIS (Recommended)
To resolve this problem, follow these steps:
Start IIS Manager. To do this, click Start, click Run, type inetmgr.exe, and then click OK.
In IIS Manager, expand server name, expand Web sites, and then click the website that you want to modify.
In the Features view, double-click Directory Browsing.
In the Actions pane, click Enable.
Method 2: Add a default document
To resolve this problem, follow these steps:
Start IIS Manager. To do this, click Start, click Run, type inetmgr.exe, and then click OK.
In IIS Manager, expand server name, expand Web sites, and then click the website that you want to modify.
In the Features view, double-click Default Document.
In the Actions pane, click Enable.
In the File Name box, type the name of the default document, and then click OK.
Method 3: Enable the Directory Browsing feature in IIS Express
Note This method is for the web developers who experience the issue when they use IIS Express.
To do this, follow these steps:
Open a command prompt, and then go to the IIS Express folder on your computer. For example, go to the following folder in a command prompt:
C:\Program Files\IIS Express
Type the following command, and then press Enter:
appcmd set config /section:directoryBrowse /enabled:true
I was exploring options for deploying my ASP.NET web app by creating a publish profile when I noticed that .pubxml files are included in this .gitignore file (which I had been using):
https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
Searching around, the reasoning seems to be that either references to the publish profile or references in the publish profile contain absolute paths or other information that may only be valid on the local dev machine at the time.
Can anyone confirm the reasoning behind this exclusion?
I cannot confirm the reasoning but I can tell you what we do. I include the .pubxml files in source control due to the fact that any of us can publish to our DEV or TEST environments. I even checked the files themselves and did not see any local paths. But consider that we use web deploy, so long as we all have access to the same server to deploy to, then there is no problem.
So it really, IMO, depends on what deployment settings you use and if all of your team have access to the same servers.
No credentials and no local paths are stored in our .pubxml files.
From Microsoft documentation (for ASP.NET Core 2.2 and up)-
When publishing to an Azure target, the .pubxml file contains your
Azure subscription identifier. With that target type, adding this file
to source control is discouraged. When publishing to a non-Azure
target, it's safe to check in the .pubxml file.
Sensitive information (like the publish password) is encrypted on a
per user/machine level. It's stored in the
.pubxml.user file. Because
this file can store sensitive information, it shouldn't be checked
into source control.
This is correct. These publish profile files have local settings like target path to deploy which may be different for different systems. So it is always kept these files only locally.
I want to create an installer for ASP.net website.
Can I use NSIS to create an installer for my web application.
So I wanted to do followings through the installation wizard.
I need to install required databases in client computer.
I need to update the connection string in web.config file based the database.
I need to create ODBC connection and save their names in my project config file.
I need to create an application in application pool of IIS.
I need to host my project in IIS.
Can someone please let me know is it possible to do those things with NSIS?If possible how can I do it?
Thanking you.
There is no exact answer for you.
You need to create a customized installer with custom pages - but it is up to you how the custom pages look like and what they do.
You can achieve this with NSIS (even with Inno Setup which is a little easier to user) but we cannot post tutorial for you.
What you need to do is to start with simple installer (default one) and add custom pages to it. It page represent some functionality:
settings database connection values
writing configuration
creating app pool
setting IIS (there are some NSIS plug-in for working with IIS)
copying files etc.
Start with some NSIS example and add more and more functionality in it until it meets your requirements.
I created an empty Azure Cloud Service project, then added a web role there. The role project has a web.config file.
When I hit F5 the role is deployed in Compute emulator. I went into the folder where role binaries are deployed - there's no web.config file there.
What's happening? Is that because I didn't set "copy always" on web.config file? What web.config does my role use?
If your role is configured for Full IIS mode (for those unaware of the difference between Hosted Web Core and Full IIS, see this blog post), the compute emulator should deploy the web role to IIS where it can be viewed in IIS Manager. On my machine (I'm running Azure SDK 1.5), the deployed web role's physical path is my source code directory.
I think web.config is compiled into your assembly as content in your development environment, and is not directly accessible like in staging/prod. You don't need to use Copy Always, if its marked as Content its all you need. You can use Environment.CurrentDirectory to see your web root path.
Even though the preferred way of storing configuration in Windows Azure applications is in the ServiceConfiguration.cscfg file, there are still many cases when you may want to use a normal .NET config file - especially when configuring .NET system components or reusable frameworks. In particular whenever you use Windows Azure diagnostics you need to configure the DiagnosticMonitorTraceListener in a .NET config file.
When you create your web role project, Visual Studio creates a web.config file for your .NET configuration. While your web application can access this information, your RoleEntryPoint code cannot-because it's not running as a part of your web site. As mentioned earlier, it runs under a process called WaIISHost.exe, so it expects its configuration to be in a file called WaIISHost.exe.config. Therefore, if you create a file with this name in the your web project and set the "Copy to Output Directory" property to "Copy Always" you'll find that the RoleEntryPoint can read this happily. This is one of the only cases I can think of where you'll have two .NET configuration files in the same project!
All info is from Azure Team Blog and I have used this solution successfully- http://blogs.msdn.com/b/windowsazure/
I get the following error when running my Visual Studio 2008 ASP.NET project (start without Debugging) on my XP Professional box:
System.Web.HttpException: The current identity (machinename\ASPNET) does not have write access to 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'.
How can I resolve this?
Have you tried, the aspnet_regiis exe in the framework folder?
I had the same problem. This is what I did:
Go to c:\windows\microsoft.net\framework\v2.0.50727
right click on "Temporary ASP.NET files"
Security tab
Select "Users(xxxxxx\Users) from Group
check "Write"
OK
Either grant that user the level of access to that directory, or change the identity that the application's application pool runs under - in IIS Manager, determine what App Pool is used to run your application, then in the App Pool section of IIS Manager, look at the properties for that pool - the tab you want is "Identity" I think (this is off the top of my head).
You can set it to another user account - for example, Crystal Reports .Net requires update and delete access to C:\Temp - so we have a "webmaster" user, with administrator access, and use that identity for those applications.
You can try to fix it using the automated regiis utility aspnet_regiis.ext available in c:\windows\microsoft.net\framework\v2.0.50727
Otherwise just manually add the needed file permissions as noted in the error.
you can right click the Visual Studio & select run as administrator.
I had this problem when trying to build a Web Deployment Project (*.wdploy).
Simply creating the folder on the framework path solved the error.
Just because the most recent answer is 5 years old, what had to be done in our environment was to delete the app, app pool and recreate them.
We evidently have some security under the hood with recent changes to it.
Doing this re-created a folder in Temporary ASP Net Files with all the correct permissions. Why the one site I happened to just get from source control, rebuild, etc. failed this way, no idea. 2 others recently set up where Get Latest Version was downloaded, rebuilt, etc. they just worked.
But ripping out the app, app pool and just recreating them with the same IIS permissions as the 2 other known working sites recreated all the needed objects and now it all works.
Make sure the ASPNET user has permission to write to that folder. Right click on the folder, Properties, Security tab.