While converting an OWIN app to the new csproj format I hit a few issues. The first issue had to do with the changed output directory (since it now includes the runtime in the path). This threw the following error:
Could not load file or assembly 'Microsoft.Owin.Host.SystemWeb' or one of its dependencies. The system cannot find the file specified.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Owin.Host.SystemWeb' or one of its dependencies. The system cannot find the file specified.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
I was able to fix this by setting the path in the Web.config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin/net461" />
</assemblyBinding>
</runtime>
After that I am now confronted with this issue:
The following errors occurred while attempting to load the app.
- No assembly found containing an OwinStartupAttribute.
- The given type or method 'ClientWebAPI.Startup' was not found. Try specifying the Assembly.
To disable OWIN startup discovery, add the appSetting owin:AutomaticAppStartup with a value of "false" in your web.config.
To specify the OWIN startup Assembly, Class, or Method, add the appSetting owin:AppStartup with the fully qualified startup class or configuration method name in your web.config.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.EntryPointNotFoundException: The following errors occurred while attempting to load the app.
- No assembly found containing an OwinStartupAttribute.
- The given type or method 'ClientWebAPI.Startup' was not found. Try specifying the Assembly.
To disable OWIN startup discovery, add the appSetting owin:AutomaticAppStartup with a value of "false" in your web.config.
To specify the OWIN startup Assembly, Class, or Method, add the appSetting owin:AppStartup with the fully qualified startup class or configuration method name in your web.config.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
I have declared the entry point using the assembly attribute:
[assembly: OwinStartup(typeof(API.Startup))]
namespace API
{
public class Startup
{ /*...*/ }
}
The "Sdk" style csproj, sometimes called the VS2017 project format, does not yet support ASP.NET 4 projects. See the following issues:
https://github.com/dotnet/sdk/issues/491 (1)
https://github.com/dotnet/project-system/issues/2670 (2)
There are two layers of issues here: (1) MSBuild and (2) Visual Studio. If you understand how targets and imports work well enough, you could workaround (1) and make the Sdk style csproj work for an Owin project.
The more difficult part is (2) - Visual Studio. When switching to the Sdk style project, under the hood, VS is switching to an entirely new implementation of the project system, the one that is open sourced in https://github.com/dotnet/project-system. This project system does not yet fully support ASP.NET 4 projects.
You can workaround (2) by using Microsoft.Owin.SelfHost instead of using Microsoft.Owin.Host.SystemWeb. To make using Microsoft.Owin.Host.SystemWeb work, VS needs to know how to generate web.config and applicationhost.config file for IIS Express, how to launch the IIS Express site, and attach to process once launched. Much of that is not ported to the new project system, and I'm not sure if it will be. The new project system was designed to work with ASP.NET Core which uses a very different method for launching and configuring IIS Express.
Related
I would like to update the web.config file by C# in windows container.
The following is a function of updating web.config in C#
private void UpdateWebConfigFile()
{
var configuration = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
var section = (System.Configuration.ConnectionStringsSection)configuration.GetSection("connectionStrings");
var defaultConnection = section.ConnectionStrings["DefaultConnection"].ConnectionString;
section.ConnectionStrings["DefaultConnection"].ConnectionString = Environment.ExpandEnvironmentVariables(defaultConnection);
configuration.Save();
}
but an error occurred in configuration.Save(); that I get the result as following
Server Error in '/' Application.
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: An error occurred loading a configuration file: Access to the path 'C:\inetpub\wwwroot\tynfsgbl.tmp' is denied.
Source Error:
An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Source File: C:\inetpub\wwwroot\web.config Line: 0
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.7.3535.0
My question is How to update Web.config in the application of Windows Container?
Thank you!
Containers are by design intended to be immutable, and as such, the default user is set to a non-admin account which will not have permissions to modify the IIS directoy.
While you can modify the runtime user to be an admin, this would present another issue due to the way that IIS inside a container is montiored. Changing the web.config would cause IIS to reset the pool, which docker would treat as a process crash and stop the container.
Either you should modify the web.config as part of the container build, or you should use environment variables directly rather than trying to write them into the web.config when the container is running.
I have a hosted MVC 4 application with MEF system in it. Everytime the system tries to create the controller that is injected by the MEF, this error occurs:
The composition produced a single composition error. The root cause is
provided below. Review the CompositionException.Errors property for
more detailed information.
1) Specified argument was out of the range of valid values. Parameter
name: site
Resulting in: An exception occurred while trying to create an instance
of type 'EAccountingControllers.EAccountingController'.
Resulting in: Cannot activate part
'EAccountingControllers.EAccountingController'. Element:
EAccountingControllers.EAccountingController -->
EAccountingControllers.EAccountingController --> AssemblyCatalog
(Assembly="EAccounting, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null")
Resulting in: Cannot get export
'EAccountingControllers.EAccountingController
(ContractName="EAccounting")' from part
'EAccountingControllers.EAccountingController'. Element:
EAccountingControllers.EAccountingController
(ContractName="EAccounting") -->
EAccountingControllers.EAccountingController --> AssemblyCatalog
(Assembly="EAccounting, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null")
It is fine If I hosted on my local IIS, but it produces error when I hosted on external hosting provider.
What is causing this error?
Try checking what is happening in the constructor of EAccountingController. I had this same issue in a Windows service/console application and it turned out that I had an unhandled exception in the constructor of the MEF part being loaded (due to an environment difference between my development and production environments).
The key part of the error message was:
An exception occurred while trying to create an instance of type '[somenamespace.sometypename]'.
In your case, it is EAccountingControllers.EAccountingController.
This is not so much a MEF error as it is an unhandled exception occurring while trying to create an instance of EAccountingController (i.e. probably in the constructor).
The answer to what the problem is likely lies within EAccountingController and what it does when an instance is being created.
I have downloaded the example code/demo from:
http://www.technowise.in/2009/12/uploadify-aspnet-c-vb-examples-demo.html
and when I try to run any of the aspx files, I just get the following message from the server:
Server Error in '/' Application.
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
Source Error:
Line 46: ASP.NET to identify an incoming user.
Line 47: -->
Line 48: <authentication mode="Windows"/>
Line 49: <!--
Line 50: The <customErrors> section enables configuration
Source File: C:\Inetpub\wwwroot\test_uploader\uploadify\web.config Line: 48
Version Information: Microsoft .NET Framework Version:2.0.50727.3623; ASP.NET Version:2.0.50727.3618
Anyone know why this is happening? I can normally run asp.net 2.0 and above web-forms perfectly will on this server.
You get this error because you have place a web.config in a subdirectory and this contains sessions that should be there, except if you define a new application/pool asp.net in this subdirectory of your iis.
From you question, here is the path of your web.config, but this must be one directory up, or not exist at all, or remove the lines that can not be there.
C:\Inetpub\wwwroot\test_uploader\uploadify\web.config
Error: Unable to generate a temporary class (result=1) ... When Invoking Methods on a Web Service. I am using VS 2008 C# ASP.NET 3.5. I am invoking a remote webservice to my application.
Server Error in '/' Application.
Server was unable to process request. ---> Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\WINDOWS\TEMP\6sbkwt2d.0.cs' could not be found
error CS2008: No inputs specified
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\WINDOWS\TEMP\6sbkwt2d.0.cs' could not be found
error CS2008: No inputs specified
Source Error:
Line 775: [System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/CheckLogin", RequestNamespace="http://tempuri.org/", ResponseNamespace="http://tempuri.org/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
Line 776: public System.Data.DataSet CheckLogin(string uname, string pswd) {
Line 777: object[] results = this.Invoke("CheckLogin", new object[] {
Line 778: uname,
Line 779: pswd});
Source File: c:\windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\14127ae4\96323535\App_WebReferences.u9ldrmk1.0.cs Line: 777
First, credit where credit is due. The OP solved this problem and answers it in the comments section of the question. However, I understand that many people come to StackOverflow and will read through the question, and not look at the comments. Therefore, I'm relaying the above answer here. Be sure to up-vote the question if this is useful.
This problem occurs because the account that is associated with your web service's application pool in IIS does not have read/write permission to the C:\Windows\Temp folder. I have no clue why the account needs access to this folder, but it does. From my casual observation it looks like it just writes an empty file with a random name to the Temp folder.
To solve this problem browse to the C:\Windows folder, and right-click on the Temp folder. Select Properties, and on the Security tab add the account associated with your web services application pool. Hit the OK button, go to IIS and recycle your application pool. This should fix your web service request.
It is worth noting that the circumstances around this error can be a bit deceptive. I've ran into this problem a couple times over 5 years. (I've forgotten about it each time.) The reason why it's not so noticeable is because you can publish a web service, successfully browse to the associated asmx page and see the outline of your web service methods. Furthermore, your Visual Studio project can add a reference to the Web Service and Visual Studio will auto-generate all associated classes for the web service in your VS project.
This gives the impression that everything is working properly until you make your first request to execute a method on the web service. The web service will fail when it begins executing code because it wants access to the temp directory.
Further information regarding this bug can be found at the acknowledged bug report at Microsoft.com.
That happens when your web site doesn't work with Application Pool "DefaultAppPool" and you chose its own pool.
In that case you need to add an user with the name of your pool.
I'm creating a custom powershell 1.0 cmdlet that will allow me to feed exceptions from powershell scripts to the Microsoft Enterprise Library v5.0 exception handling block.
I load up my Exception handling config from an external file since the cmdlet is compiled into a dll, and then try to create an instance of ExceptionManager using the config.
Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource config =
new Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource(configFile);
WriteDebug("Config loaded from " + Path.GetFullPath(configFile));
EnterpriseLibraryContainer.Current = EnterpriseLibraryContainer.CreateDefaultContainer(config);
exManager = EnterpriseLibraryContainer.CreateDefaultContainer(config).GetInstance<ExceptionManager>();
This fails when I call my command from powershell with the following error:
Microsoft.Practices.ServiceLocation.ActivationException: Activation error occured while trying to get instance of type ExceptionManager, key "" ---> Microsoft.Practices.Unity.ResolutionFailedException: Resolution of the dependency failed, type = "Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionManager", name = "(none)".
Exception occurred while: while resolving. Exception is: InvalidOperationException - The type ExceptionManager cannot be constructed. You must configure the container to supply this value.
The frustrating thing is that the code works perfectly fine when used in a stand-alone console application with the exact same configuration. I'm not really sure why I'm getting this error; I've made sure that I'm using the same assemblies that are referenced in the config file and I've made sure that I'm referencing all the necessary enterprise library dlls in my project.
Additionally, I've had to copy the Enterprise Library dlls into the powershell install directory (%SystemRoot%\system32\WindowsPowerShell\v1.0), otherwise I would receive FileNotFoundExceptions about not being able to find the correct library while the configuration file was being processed. I don't have too much experience with powershell or enterprise library, but I'm guessing that this might be resolved by playing around with AppDomain settings.
Turns out I wasn't giving an absolute path to my configuration file, which was causing weirdness. I originally just set it to "widgit.dll.config", and threw it under %systemroot%\System32, since that's the default working directory of my powershell, and seemed to get rid of the initial "file not found" errors I was having (didn't want to change the working directory until I understood the entire problem). On a hunch, I copied the config into the powershell directory and renamed it powershell.exe.config, and that solved my other problem.
Putting stuff into system directories isn't the most elegant solution at this point, but it's sufficient for my current problem.