I've got a Windows 2012 r2 server with IIS 8.5 running on it.
I am trying to deploy a new web app in a sub folder of the root website. This is my third web app that I will have up there and the prior two are fine, but for some reason this app when I use Web Deploy to push it doesn't fully populate all of the Features for the app.
I had to manually enter Application Settings and Session State is completely greyed out so I can't even fill in what exists on the other web apps I've published.
Recently I upgraded to VS 2017 so I thought it might be a glitch in my setup so I ripped one of the two existing apps out and did a re-deploy on them and they work perfectly.
I'd post more info but I am not sure what someone helping might want to see.
Any ideas on what's going on?
Updated: May Monday 15th,7:50AM Central US --
I went back and looked at the Features view and compared the content from the working app (republished as a test and still worked fine) and this one that I'm having the difficulty with. Here are the results. (this with 100% success reported in Web Deployment publish)
I am able to edit the first two of these feature items to make them identical to the working app but not the third. All options on this are grayed out:
Related
I have basically installed the default Blazor WebAssembley template, with .Net Core server.
Ran the app, worked fine, comes with the initial migration for identity which ran and created the database tables so I could create an account login etc.
Changed 1 view file razor file and now the app will not run. In debug mode I can see the it seems to be empty, so the application falls over when it tries to connect to the DB with an empty connection string.
I just ran through the exact same steps on another machine and the same result, yet the only files changed are the appsettings.json and a razor file.
appsettings worked fine, then without changes no longer works. Any suggestions on where to investigate would be appreciated - this is my first step into .Net Core.
So just in case anyone else comes across this problem. I had the application open in another browser window, although I was not interacting with it.
Once I closed all the browser windows and ran the application again I no longer had the issue.
One thing to note, I am running IIS Express with the option "Do not start browser" so that VS does not keep closing and opening a new browser window.
I had Application Insights running smoothly on an Azure Web App via the AI SDK, reporting to an AI instance hosted in Azure.
The only niggle was it didn't show detailed dependancy diagnostics, according to this page this was because I was using the SDK only, I needed to "Instrument your web app on the server", which looking at the docs can't be done if you already have an instance of AI running....helpful!
Reluctantly I deleted the AI instance, stripped the SDK from my code so I was starting fresh, and followed the steps, however as soon as I finished the process in the previous link my website broke and now responds to every single request (MVC5 and Web API) with an empty 404 request
The AI status page is showing green ticks for everything, and I can't discern anything from diagnostic log dump from KUDO or manage to remotely debug the site.
Deleting the AI extension under Web App -> Extensions in the Azure portal and then restarting the web app fixes the problem.
I've run out of ideas on how to fix this, is there anything else I can do to get to the bottom of the problem?
To fix this problem, delete the following 2 files from your web app's (or slot's) filesystem:
D:\home\siteextensions\Microsoft.ApplicationInsights.AzureWebSites\Instrumentation32\ProductionBreakpoints_x86.config
D:\home\siteextensions\Microsoft.ApplicationInsights.AzureWebSites\Instrumentation64\ProductionBreakpoints_x64.config
You can do this easily through Kudu.
Edit: Apparently this is/was an issue with the ProductionBreakpoints interacting with precompiled views. Microsoft has informed me a fix should be out within the next couple days. The version of Application Insights extension I have now that is still broken is 2.4.6 - I will post the "fixed" version when I can confirm it.
Edit 2: Confirmed this is fixed in 2.4.7 which is out now.
I have a Website project (not Web Application), don't ask me why and whether I can turn it into a Web Application. Whenever I build solution, it won't build website, and when I hit play (Start Debugging), it always launched the project and built/compiled the pages ask I browsed the application. Well, until I installed VS Updates last night. How Starting Debugging builds the whole website, every directory and the process takes 20-25 minutes. I would love to disable that new feature that the VS2017 Update installed. How can I do that?
I am using VSc2017 v15.1 (26403.7)
Found my answer at a different question on SO.
I disabled the Build of Website in the Startup Action of the Website in property pages.
This is my first ASP.NET project so I am a bit of a rookie when it comes to a lot of the configuring of IIS/Visual Studio so bear with me...
I am using Visual Studio 2010 running on Windows Server 2008 SR2. We recently did some updates on the server and now my project no longer loads when I attempt to debug. When I try to debug the default "Welcome" page for IIS 7 loads instead of my project. I am set up to use the development server to debug, not IIS so I don't understand why I get the IIS page. Before the updates the debugger was pulling up my page without any issues.
Any ideas? Thanks in advance!
It looks like IIS is now bound to the port number that Visual Studio Development Web Server was using previously. You can change the port number in the properties of the web site project.
I have found a solution to my issue. I decided to use IIS instead of the Development Server for debugging. After attempting to debug unsuccessfully yet again, I took a look at the identity that was being used in the application pool and I changed to one with more privileges and that seemed to do the trick. Thanks for the suggestions.
I had the same problem but non-of the earlier answers worked.
I am using Windows 7 enterprise 64-bit, IE11, VS2010, Silverlight 5
I have been developing and maintaining a number of Silverlight projects for the past 5 years, and have always been able to debug them within VS2010 using the ASP.NET Development Server. However, on returning from some well deserved holiday, I found that none of my existing Silverlight projects would run in the debugger. In each case there is a Web project set as the start-up project, and in each case on starting the project within VS2010 (with or without debugging) I got the IIS7 web page instead of my application.
I tried creating a new Silverlight web application, and found that this started normally in the ASP.NET Development Server. I checked my source code and found that no changes had been made in my absence.
After a lot of head scratching, etc., the solution was to clear the IE cache. These are the explicit steps I used:
Close all instances of IE and ASP.NET Development Server.
Open Internet Properties from the Control Panel.
Click "Delete" on the General Tab.
In the Delete Browsing History box check the following options:
a) "Preserve Favourites website data"
b) "Temporary Internet files and website data"
c) "Cookies and website data"
Leave the others unchecked
5) Click "Delete" and wait for the command to complete.
6) Close the Internet Properties box.
7) Rebuild ASP.NET project
8) Start (with or without debugging) in VS2010 - it should now load normally.
Hope this works for you.
I have basic forms authentication set up and it works just fine locally against IIS express. When I deploy, the sitemap security trimming stops working (menu items are showing that shouldn't be there). If I try and go to one of the nodes that shouldn't be there with a user that does not contain the role required, they get kicked back to the the login screen. Because of that that, I know authentication is working properly.
Another developer I work with has it working just fine locally on his machine as well. The deployed web server is where it no longer works.
I don't believe there is a problem with any of the markup sine it works locally, so I'll withhold from posting the code. Every single example on the web matches up with what I have. The code also resides on a network on with no outside access.
No other posts have been found where someone ran into this issue.
Thanks in advance
After lots of experimenting, we think we narrowed it down. We are forced to use cookie-less session state on this system and that seems to be the problem. Our development machines have a major difference in that they have .net 4.5 installed on them. The production server as well as a few other developers only have .net 4.0 installed. If we allow a cookie, it works just fine. It seems that the paths are not being handled properly on the 4.0 machines in cookie-less session state which breaks the security trimming. Some more testing is needed to verify this. Unfortunately updating the production machine is not an option.