I have an ASP.NET 3.1 project that get published to a windows server. When I run the project locally on my computer, it works fine; however, when I remote desktop into that windows server, I am getting a 500 error in the network tab and the following error:
I have changed my environment variable to Development in my Launch.json file, but still received the same error
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
When I looked in windows Event Viewer, I found this error:
Can someone help me figure out what is going on with this?
Please check the value of ASPNETCORE_ENVIRONMENT variable. You will have to set this environment variable to "Production"(or other environment than Development).
Otherwise, you can update web.config like this:
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\Application.exe" arguments="" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables>
</aspNetCore>
</system.webServer>
</configuration>
Refer this post for more details.
Related
While trying to build on tfs a .net Code 2.2 solution have a nuget restore task. it's trying to connect to our internal feeds. Then it fail. In the build logs we have :
error : Unable to load the service index for source http://internalSource/index.json. [D:\dummy.csproj]
error : No credentials are available in the security package [D:\dummy.csproj]
Looking at TFS generated files, it's not using the credential we declare in our solution.
Our nuget.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageRestore>
<!-- Allow NuGet to download missing packages -->
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<packageSources>
<clear />
<add key="PackageSTN" value="http://internal/index.json" />
</packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
<packageSourceCredentials>
<PackageSTN>
<add key="Username" value="user" />
<add key="Password" value="pwd" />
</PackageSTN>
</packageSourceCredentials>
</configuration>
The one on TFS the build give us:
<configuration>
<packageRestore>
<add key="enabled" value="True"/>
<add key="automatic" value="True"/>
</packageRestore>
<packageSources>
<clear/>
<add key="PackageSTN" value="http://internal/index.json"/></packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)"/>
</activePackageSource>
<packageSourceCredentials>
<PackageSTN>
<add key="Username" value="VssSessionToken"/>
<add key="ClearTextPassword" value="Too Big to be display"/>
</PackageSTN>
</packageSourceCredentials>
</configuration>
Seem like it's trying to use some VssSessionToken TFS account to log on.
In addition we replace the %APPDATA% nuget.config on the server with the one with our credential, in case it will have a look inside, no luck as well.
TFS build .net Core with nuget restore end in error
As we know, when we select the option Feeds in my NuGet.config, we also need provide the Credentials for feeds outside this account/collection:
If we use the token we got from CredentialProvider.VSS.exe in the field "Personal Access Token" in the NuGet connection window, we may got the issue like you. The token we got from CredentialProvider.VSS.exe is a short-lived token, you could replace it with PAT (Personal Access Token) to check if it work for you.
Check this thread for some more details.
Besides, if you are using the old nuget.exe, you can use the task NuGet Tool Installer to update it.
If above not help you, please share your build definition about nuget restore task and the steps how to add the Credentials for feeds outside this account/collection.
Hope this helps.
Finally we did a powershell script, to by-pass this :/
try
{
$solutionSln = $env:BUILD_SOURCESDIRECTORY + $env:solutionSln
$nugetConfig = $env:BUILD_SOURCESDIRECTORY + $env:nugetConfig
Write-Host "dotnet restore $solutionSln --configfile $nugetConfig --verbosity Detailed --no-cache"
dotnet restore $solutionSln --configfile $nugetConfig --verbosity Detailed --no-cache
}
catch {
Write-Host $_
exit 1
}
I've been looking for a best practice recommendation on how to deploy an application with a WiX installer for different values in its App.config file. For example.
On my local development machine, I use App.config settings for our test environment:
<configuration>
<appSettings>
<WorkingDirectory>C:\Working</WorkingDirectory>
</appSettings>
<connectionStrings>
<add name="ApplicationEntities"
connectionString="[TestingConnectionString]"
providerName="System.Data.EntityClient" />
</connectionStrings>
</configuration>
When I deploy to a test environment, those settings are acceptable. However, when we deploy to a production environment, I'd like them to be different. For example:
<configuration>
<appSettings>
<WorkingDirectory>\\prodserver\Working</WorkingDirectory>
</appSettings>
<connectionStrings>
<add name="ApplicationEntities"
connectionString="[ProductionConnectionString]"
providerName="System.Data.EntityClient" />
</connectionStrings>
</configuration>
The answer to my question may very well be independent of WiX. But just in case, here is my WiX Product.wxs file's relavent fragment:
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="ProductComponent" Guid="{MY-GUID}">
<File Id="Application.exe"
Name="Application.exe"
Source="..\Application.exe"
Vital="yes"
KeyPath="yes"
DiskId="1" />
<File Id="Application.exe.config"
Name="Application.exe.config"
Source="..\Application.exe.config"
Vital="yes"
KeyPath="no"
DiskId="1" />
</Component>
</ComponentGroup>
</Fragment>
This setup ends with a manual edit of the App.config on the production server, which invites manual error. What would be a better way to handle this to accommodate an automated deployment?
I can think of two options, either deploy the app.config file and edit it using the XmlFile Element, or maintain multiple app.config files each representing your target environment, then deploy the appropriate file.
Here's an exmaple of both options, notice that I copy the file rather than just placing it on the file system. This serves two purposes, firstly you can see by the filename which one has been deployed, secondly if development.app.config and production.app.config are placed in the same location you will get an ICE30 validation error, by copying the file afterwards it avoids this error.
Notice also that I have a condition associated with the component, you'll need to decide how you identify which environment you are deploying to. Some ideas could be to use the machine name, the OU or simply pass it in on the command line as a property.
<Component Id="development.app.config" Guid="*">
<Condition>DEVELOPMENT</Condition>
<File Name="development.app.config" KeyPath="yes">
<CopyFile Id="development.app.config" DestinationName="app.config" />
</File>
<util:XmlFile
Id="WorkingDirectory"
Action="setValue"
File="app.config"
ElementPath="/configuration/appSettings"
Name="WorkingDirectory"
Value="C:\Working"
Permanent="no" />
</Component>
<Component Id="production.app.config" Guid="*">
<Condition>PRODUCTION</Condition>
<File Name="production.app.config" KeyPath="yes">
<CopyFile Id="production.app.config" DestinationName="app.config" />
</File>
<util:XmlFile
Id="WorkingDirectory"
Action="setValue"
File="app.config"
ElementPath="/configuration/appSettings"
Name="WorkingDirectory"
Value="\\prodserver\Working"
Permanent="no" />
</Component>
I'm trying to pick up the windows username when debugging in Visual Studio 2013. I am simply using:
httpcontext.current.user.identity.name
If I run this on my Dev Server it works fine, if I run it in debug mode on any previous version of Visual Studio it also works fine.
My problems is - If i run this on visual studio 2013 I get an empty string.
My web config is as follows.
<system.web>
<authentication mode="Windows"/>
<identity impersonate="false"/>
<authorization>
<allow users="*"/>
</authorization>
<compilation debug="true" strict="false" explicit="true" targetFramework="4.0"/>
<customErrors mode="Off"/>
</system.web>
I had just upgraded to VS 2013 from VS 2012 and the current user identity (HttpContext.User.Identity) was coming through as anonymous.
I tried changing the IIS express applicationhost.config, no difference.
The solution was to look at the properties of the web project, hit F4 to get the project properties when you have the top level of the project selected. Do not right click on the project and select properties, this is something entirely different.
Change Anonymous Authentication to be Disabled and Windows Authentication to be Enabled.
Works like gravy :)
As I was researching this I found my answer, but can't find the answer on the internet, so I thought I'd share this:
I fixed my issue by modifying my applicationhost.config file. My file was saved in the "\My Documents\IISExpress\config" folder.
It seems that VS2013 was ignoring my web.config file and applying different authentication methods.
I had to modify this portion of the file to look like the below. In truth, I only modified the anonymousAuthentication to be false and the windowsAuthentication mode to true.
<authentication>
<anonymousAuthentication enabled="false" userName="" />
<basicAuthentication enabled="false" />
<clientCertificateMappingAuthentication enabled="false" />
<digestAuthentication enabled="false" />
<iisClientCertificateMappingAuthentication enabled="false">
</iisClientCertificateMappingAuthentication>
<windowsAuthentication enabled="true">
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
</windowsAuthentication>
</authentication>
In Visual Studio 2013 AND VS15 (but i guess if the same for all other version) just press F4 and change this two properties:
-Anonymous Authentication: Disable
-Windows Authentication: Enable
In VS2013 F4 on your project to view properties window and disable Anonymous access and enable "Windows authentication"
Then it will work. No need to change anything else
VS 2015 changes this. It added a .vs folder to my web project and the applicationhost.config was in there. I made the changes suggested (window authentication = true, anon=false) and it started delivering a username instead of a blank.
Open up the applicationHost.config file located in the C:\Users[userid]\Documents\IISExpress\config folder. Inside this file change the overrideModeDefault of anonymousAthentication and windowsAuthentication to "Allow"
<sectionGroup name="security">
<section name="access" overrideModeDefault="Deny" />
<section name="applicationDependencies" overrideModeDefault="Deny" />
<sectionGroup name="authentication">
<section name="anonymousAuthentication" overrideModeDefault="Allow" />
<section name="basicAuthentication" overrideModeDefault="Deny" />
<section name="clientCertificateMappingAuthentication" overrideModeDefault="Deny" />
<section name="digestAuthentication" overrideModeDefault="Deny" />
<section name="iisClientCertificateMappingAuthentication" overrideModeDefault="Deny" />
<section name="windowsAuthentication" overrideModeDefault="Allow" />
</sectionGroup>
Next change lockItem to be "false" for AnonymousAuthenticationModule and WindowsAuthenticationModule
<system.webServer>
<modules>
<!--
<add name="HttpCacheModule" lockItem="true" />
-->
<add name="DynamicCompressionModule" lockItem="true" />
<add name="StaticCompressionModule" lockItem="true" />
<add name="DefaultDocumentModule" lockItem="true" />
<add name="DirectoryListingModule" lockItem="true" />
<add name="IsapiFilterModule" lockItem="true" />
<add name="ProtocolSupportModule" lockItem="true" />
<add name="HttpRedirectionModule" lockItem="true" />
<add name="ServerSideIncludeModule" lockItem="true" />
<add name="StaticFileModule" lockItem="true" />
<add name="AnonymousAuthenticationModule" lockItem="false" />
<add name="CertificateMappingAuthenticationModule" lockItem="true" />
<add name="UrlAuthorizationModule" lockItem="true" />
<add name="BasicAuthenticationModule" lockItem="true" />
<add name="WindowsAuthenticationModule" lockItem="false" />
Making these changes will allow the existing web config settings to override what is in the applicationHost file for IIS Express.
You could also modify the project properties for your web project, choose "Web" from left tabs, then change the Servers drop down to "Local IIS". Create a new virtual directory and use IIS manager to setup your site/app pool as desired.
I prefer this method, as you would typically have a local IIS v-directory (or site) to test locally. You won't affect any other sites this way either.
It appears that the right answer is provided by user3149240 above. However, As Neil Watson pointed out, the applicationhost.config file is at play here.
The changes can actually be made in the VS Property pane or in the file albeit in a different spot. Near the bottom of the applicationhost.config file is a set of location elements. Each app for IIS Express seems to have one of these. Changing the settings in the UI updates this section of the file. So, you can either change the settings through the UI or modify this file.
Here is an example with anonymous auth off and Windows auth on:
<location path="MyApp">
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" />
<anonymousAuthentication enabled="false" />
</authentication>
</security>
</system.webServer>
</location>
This is equivalent in the VS UI to:
Anonymous Authentication: Disabled
Windows Authentication: Enabled
F4 doesn't always bring me to this panel. Besides, it is often said that a picture is worth a thousand words.
Tried every possible setting found on stackoverflow and the Internet but no luck. Wish the developer of ELMAH had insight to show messages from ELMAH itself. ELMAH xml logging works fine.
Hope someone here will point out misconfiguration in web.config
<configSections>
<sectionGroup name="elmah">
<section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah" />
<section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah" />
<section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler, Elmah" />
<section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler, Elmah" />
</sectionGroup>
</configSections>
<modules runAllManagedModulesForAllRequests="true">
<remove name="ErrorLog" />
<remove name="ErrorMail" />
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah" />
<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah" preCondition="managedHandler" />
</modules>
<errorMail from="from email" to="to email" subject="elmah exception" smtpServer="smtp.gmail.com" port="587" userName="xxxx#gmail.com" password="gmailpassword" useSsl="true" async="true" >
</errorMail>
Have tried user name without #gmail. Have tried locally installed server in errorMail settings but no help. The locally installed server works fine otherwise.
Have also tried this:
<system.net>
<mailSettings>
<smtp deliveryMethod="Network">
<network host="smtp.gmail.com" port="587" userName="xxxxxxxxxxx" password="xxxxx" />
</smtp>
</mailSettings>
</system.net>
used these settings for local smtp server:
<errorMail from="from email" to="to email" subject="elmah exception" smtpServer="xxx IP address of smtpserver" port="25" userName="xxxxx" password="xxxx" async="true" >
</errorMail>
All in all, I have tried all combinations, different settings, different SMTP servers.... no luck. Don't know if there is some message somewhere from ELMAH that I can see to know why ELMAH not connecting to STMP.
As stated above, I went through every post on this site that talks about ELMAH email and followed the instructions... but still couldn't make it work.
Also tried local smtp pickup directory
<smtp deliveryMethod="specifiedPickupDirectory">
<specifiedPickupDirectory pickupDirectoryLocation="C:\inetpub\mailroot\Pickup" />
</smtp>
and monitored the directory. Saw no activity in the folder.
Using ELMAH 1.2
This article explains how to capture the internal error of ELMAH: http://ericmbarnard.blogspot.co.uk/2012/07/debugging-elmah-on-azure.html
It just saved me a few minutes ago by telling me why my logging to SQL wasn't working :-) Although it mentions Azure you can use the same technique with local debugging, and you'll be able to write to the debug trace listener and avoid having to write to a database.
I have a web service written with Visual Studio 2005. My web.config file contains this:
<system.diagnostics>
<trace autoflush="true" indentsize="4" />
</system.diagnostics>
But any call to System.Diagnostics.Trace.WriteLine is ignored. When I step through my code, those lines are skipped over.
Is there another way I should be turning on tracing? How can I tell why tracing is turned off?
I had to add this to my web.config:
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp"
extension=".cs"
compilerOptions="/d:TRACE"
type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.3500.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="1" />
</compilers>
</system.codedom>
I got that from Microsoft's Troubleshooting Web Services article.