In my publish profile for staging (/Properties/PublishProfiles/xxx.pubxml) I have:
<EnvironmentName>Staging</EnvironmentName>
I have a file called appsettings.Staging.json.
When I deploy to the server the file stays as appsettings.Staging.json and doesn't get turned into appsettings.json, as I would expect.
Am I missing a step, shouldn't the transformation take place automatically.
The website doesn't work with appsettings.Staging.json file there.
In web.config on the server there is:
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Staging" />
which was added because of the line I added to the publish profile.
Ok, there is no issue here, I mis-understood how it works.
The website wasn't working because in my DAL (Data Access Library) class library it was looking for a file called appsettings.json so it could get the connection string for EF core, which didn't exist. I changed it to look for appsettings.{environment}.json by getting the ASPNETCORE_ENVIRONMENT environment variable at runtime and it works now.
I am trying to publish as ASP.NET Core project with a hosting provider that supports ASP.NET Core. I am getting 500 Internal Server Error which I believe is very common. So I searched through the internet and various forums and then I checked the processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" in web.config and they look to be correctly converted with processPath="dotnet" and arguments=".\MyApplication.dll".
I also checked the connection string and it points to production DB server that's working. I confirmed the DB connection by changing the connection string to production DB and running project local. It works and I get the production DB access.
I also tried to get the error info by using the below in my Startup.cs (irrespective of env):
app.UseDeveloperExceptionPage();
app.UseDatabaseErrorPage();
app.UseBrowserLink();
I have also enabled stdoutLog in web.config, but I don't see that folder either:
stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout"
I also tried to change applicationUrl and launchUrl in launchSettings.json to my prod Url, but that didn't work as well.
So, the 500 Internal Server Error refuses to go away, and I still don't have a useful error message. The page just says:
Oops.
500 Internal Server Error
An error occurred while starting the application.
I would really appreciate if someone could help me here.
I have also enabled stdoutLog in web.config as but I don't see that folder either:
stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout"
There is one trick here - you must create both folders logs and stdout manually - then and only then IIS will create log file inside logs folder (not stdout as you could expect) - don't ask me why, because I don't know why ;)
Oops. 500 Internal Server Error An error occurred while starting the application.
Usually, means problems with a configuration in Startup.cs - the most common problems include an issue with DB itself, an issue with migrations (if you are using Code First approach), problems with appsettings.js, problems with Social Logins credentials (like missing SecretKey)...
Please refer to log file in .\logs\stdout - this is the quickest way to find details about the problem :)
app.UseDeveloperExceptionPage();
app.UseDatabaseErrorPage();
Those will work after your WebApp fully started, but not while starting the application.
in web.config file change modules="AspNetCoreModuleV2" to modules="AspNetCoreModule"
and watch this video
https://www.youtube.com/watch?v=clCR3k6kkD8
Thanks to Lukasz for his comments. I was able to see the log and it stated that "ClientId option must be provided". The problem was with the UserSecrets. Since secrets.json is only available in Development, there were no secrets found in Production. Once I had the secrets in my appSettings.json, it worked fine.
Moreover, To replicate this in Local environment, just go to Project properties and change the environment variable ASPNETCORE_ENVIRONMENT to 'Production' and run in local. This will replicate the 500 Internal Server Error in local and you'll get the error message.
Also, ensure that the ASP.NET Core Windows Server Hosting bundle is installed. THis creates a reverse proxy between IIS and the Kestral server.
More Info:
https://learn.microsoft.com/en-us/aspnet/core/publishing/iis?tabs=aspnetcore2x#tabpanel_tfsY37MhAQ_aspnetcore2x
I would like to add some more info to #Lukasz Makowej answer.
I found out the reason why to have to create the folder, in microsoft documentation it is said that:
stdoutLogFile - Optional string attribute.
".....Any folders provided in the path must exist in order for the module to create the log file...."
So you have to create it yourself :)
Check it out here:
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module?view=aspnetcore-2.0
I also must said that in my case I had to validate that the web-site had the permissions to access to the "log" folder.
Make sure your web.config is good. I've been stomped more than once by a syntactically good web.config that referred to a module (Rewrite) that wasn't on the server. No error messages anywhere, other than the 500 response error.
Std log wasn't working for me, I had to uninstall all .ENT Core runtime / SDK versions from the server and my local to install the latest one and it worked after publishing everything again from scratch.
Another thing that helped was binding the IIS app to port 5000 without any dns so it actually showed me errors on http://localhost:5000
Encountered this issue yesterday, we also had no logging, no eventlog message whatsoever.
Then we checked the site's authentication settings via the IIS-manager to double-check the settings. And pop suddenly a popup with an error message 'Error on line XXXX'.
Turned out the configuration section was locked in the website's config at server-level.
So try unlocking the relevant IIS configuration settings at server level, as follows:
Open IIS Manager
Select the server in the Connections pane
Open Configuration Editor in the main pane
In the Sections drop down, select the section to unlock, e.g. system.webServer => security => authentication
Click Unlock Attribute in the right pane
Repeat for any other settings which you need to unlock
Restart IIS (optional) - Select the server in the Connections pane, click Restart in the Actions pane
I'm feeling stupid.
I've just created my first ASP.net 4.0 site after working my way though over the years from 1.1 upwards. We have several settings at the machine.config level that I need to migrate to the new 4.0 machine.config. I though I had be adding the required connection strings to the connection string section of the following two files:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\machine.config
C:\Windows\Microsoft.NET\Framework\v4.0.30319\machine.config
When I created a new website in IIS and assigned it to the ASP.net 4.0 Application pool I only get the default LocalSqlServer connection string. I tried editing the name of this in the two files above to indicate which file it was in, but there was no change.
Are there machine.config files in other locations I should be looking at?
Due to the wonders of microsoft putting the machine.config a few location the locations I actually wanted was:
C:\Windows\Microsoft.NET\Framework64\v4.0.3031\CONFIG\machine.config
C:\Windows\Microsoft.NET\Framework\v4.0.30319\CONFIG\machine.config
I had the same issue. I did't realize that my ConfigurationManager.ConnectionStrings["ConnectionNameWhateverItIs"].ConnectionString was looking at the Framework64 location. You can put the following line in your code to get location of the Machine Config file being used:
string connString = ConfigurationManager.OpenMachineConfiguration().ConnectionStrings.CurrentConfiguration.FilePath;
I am developing a simple wcf service for test. When I test this service with my local IIS 7.5, then it works properly. But when I host it in web IIS, I receive this error:
The type 'WcfServiceLibrary1.Service1',
provided as the Service attribute
value in the ServiceHost directive, or
provided in the configuration element
system.serviceModel/serviceHostingEnvironment/serviceActivations
could not be found.
And my ServiceHost is:
<%# ServiceHost Language="C#" Debug="true" Service="WcfServiceLibrary1.Service1" %>
Please help me resolve this problem
Because I couldn't find this suggested in any of the questions I looked through for this, adding my case here:
I had this problem when I manually changed the namespace in the file MyService.svc.cs, and did not change the Service name in the corresponding file MyService.svc - turned out that it needed to be Service="namespace.classname".
Try using the assembly qualified type name.
This is [Fully Qualified Type Name], [Assembly]
Where [Fully Qualified Type Name] is, in the most common cases YourNamespace.YourType
And [Assembly] is, in the most common cases YourAssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
It gets more complicated than this (generic types, nested types etc) - but unlikely to be so in your case.
If your application is using the default build options, then I'm going to hazard a guess that the directive should be something like this:
<%# ServiceHost Language="C#" Debug="true"
Service="WcfServiceLibrary1.Service1,
WcfServiceLibrary1,
Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=null" %>
Although you'll probably want to get rid of the newlines there.
Also, make sure your dll has actually been deployed
I had the same issue only when publishing my service but it worked locally.
It turned out to be that the service was referencing a DLL that wasn't being deployed. It's a super special case because it was a system dll (System.Web.Helpers) and thus the project didn't even have a reference to it and thus the "Copy Local" wasn't set to true.
IIS defaults to expecting to see the svc file in the virtual directory, and the binaries inside a bin folder (as marc_s commented).
However, the default build configuration for WCF Library projects is to build inside a bin/Debug folder (or bin/Release). You can change the Output Path to 'bin/' on the project properties Build tab.
Changing this resolved this error for me today.
I had this same problem after I deployed a working service to a new location (new site) in IIS. In inetmgr under the Default Website tree, I hadn't right-clicked the new site and selected Convert to Application - all working now!
Finally my problem solved.
I removed the service directory in my host and created a new virtual directory in the host space. Then I copied my service in new directory where I created it.
Now I can browse the .svc file for service and my client will consume the service.
I don't understand why this problem occurred! I am a little confused!
The answer marked as answer is very difficult to understand. In fact, although it led me to solve my similar problem, I don't know if that's because I accurately understand what the writer was meaning.
I was finding if I pointed an IIS application on my development machine to the actual project directory in which resides the web.config, MyService.svc, and bin folders necessary for the WCF Service Application it just wouldn't work, and was throwing this error. This is despite quadruple checking every setting and ensuring that things were equivalent to other simple, working WCF Applications.
Ultimately, I solved the problem by publishing to a different directory rather than depending on the project files and directory themselves.
Perhaps it was because the files were open in Visual Studio as I was trying to run the WCF application through IIS? I don't know, but the Visual Studio provided localhost:59871/... was working. I don't know if that instance is using the project files or a temporary published version.
Check whether namespace and class written in "Service" of "SeviceHost" is correct .It should be Service="namespace.classname" .
Another reason for this issue is often when a wcf service is moved from one directory to another, and the svc file has not been updated... easiest solution is to double check your .svc file and make sure the service definition is defined correctly.
As I can't up vote #jeromeyers answer at the moment, I want to add that this is the solution that I found for this issue.
Someone had copied and pasted a svc file and associated contract and code files to a new project, but they had not updated the namespaces and class names everywhere. Very frustrating tracking this down as it started with this error :
" name was started with an invalid character. Error processing resource 'file:///C:/...
<% #ServiceHost "
when trying to right click on the .svc file and doing "View in browser".
Even though this is slightly different than the question (not web iis): I got here through search because I was getting this error trying to Debug my service -- if you have multiple services inside a single solution, this error will occur if the solution in question is not built yet, and therefore the DLL not created when you try to access it. So to anyone out there make sure if running locally that the entire solution is built!
had this problem running a test project that was embedded in my solution.
I had to view in browser, then copy that link to a new service reference (delete the old one) then paste it in rather than using the discover utility button in the service reference.
Strange as well, after looking and trying others suggestions, i was still getting the error saying the:
The type ', provided as the Service attribute value in the ServiceHost directive, or provided in the configuration element system.serviceModel/serviceHostingEnvironment/serviceActivations could not be found.
Sure we all get large project with a lot of DLLs. Turned out some of the older components in my solution were targeting .Net 4.5, and newer dll were build with 4.5.1. When the 4.5 dlls referenced the 4.5.1 dlls .... Not sure why i was the happy little guinea pig to be the first on my team to find this. While the fix was obvious and easy enough, just all the dlls to target the same .Net runtime.
Just wish Visual Studio would notice DLLs within the same solution should all target the same .Net runtime and generate a warning/error when building especially with we have a solution and a project reference and the runtimes don't match...
Be sure your compiled dlls are moved to service(IIS directory)
directory.
For example, sometimes Jenkins doesn't move them automatically.
I had the same issue when i uploaded my working localhost service to a new location on host.
I create a new Virtual Directory and published my Service to it via Visual Studio(FTP). Problem Solved.
It happend the same to me and the solution was creating a forder named "bin" and place the dll inside of it. Then, refresh the website on IIS and that's all
I had this problem too, and what did the magic for me was to restart the IIS.
This is a very weird error.
First time hosting WCF Service Application, in IIS ?
Many have solved their problems one way or the other. However if everything is your solution is correct and your error is about host your app in IIS, then ensure your physical path in IIS when you add your website is pointed to the "bin" directory of your solution as seen below in the screen shots.
Please look at https://msdn.microsoft.com/en-us/library/ms733766(v=vs.100).aspx
You need to do 2 things to be able to Host the Service on IIS, or even on Visual Studio's itergrated IIS_EXPRESS.
1) Update the Web.Config to include ServiceActivations
change:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
to
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">
<serviceActivations>
<add service="API.Service1" relativeAddress="Service1.svc"/>
</serviceActivations>
</serviceHostingEnvironment>
2) You need to create a directory called App_Code in the root directory.
You now need to move the Service (ex: Service1.svc) from the root directory into the App_Code directory.
So you will have App_Code\Service1.svc
If you browse the Service
http://localhost:63309/Service1.svc it should work.
I have 1 c# Console Application project, which has Program.cs (that contains main method), the main method simple calls a web service method and displays the string on the console.
The service reference is added in the project by right clicking it and adding service reference it to it.
when the console application is executed in debug mode from visual studio, it works as expected.
when the console application is executed from a .exe found in /bin/debug, it works as expected.
so far so good.
PROBLEM:
when the project is copied over to the system (you can call it a production environment), where this .exe will actually be executed, it fails at the exact line where i create the service proxy object. the line in Program.cs is:
ProjectName.ServiceReference.ServiceClient service = new ProjectName.ServiceReference.ServiceClient();
I know it fails here, because i have Console.Writeline("some line"); before and after the above line. I can see the Console.Writeline that is before the proxy line, and soon after that it crashes ...
I think this is because the reference paths that are referencing the service, is there any thing i can do to change the paths, or confirm that it is the path issue as suspected ...??
any idea whats going wrong ..???
Check this link: http://blog.davidsandor.com/post/Workaround-The-configuration-for-the-servicee280a6Unrecognized-element-e28098extendedProtectionPolicye28099.aspx
The configuration for the service reference could not be updated due
to the following issue: Unrecognized element
‘extendedProtectionPolicy’. (App.config / Web.config)
There does not seem to be a really clear reason why this is happening
however it seems to be related to Windows 7. I am not sure if the
.NET framework that ships with Win7 has some different setting or
template for the WCF configuration policy files but it seems to be the
culprit. Maybe the machine.config files are different on Win 7 and
the WCF configuration tools use the machine.config as some sort of
policy template.
The fix is annoying (because every time you build your solution on
Windows 7 and then rebuild on Vista you have to redo this).
Remove the line:
<extendedProtectionPolicy policyEnforcement="Never" />
from both your App/Web.config file on the client and on the WCF
server’s Web.config file.