I have an ASP.NET application that runs fine on my local machine. I just uploaded it to a server using web deploy. I'm getting the following error when I try to view the site:
The following errors occurred while attempting to load the app.
- The OwinStartup attribute discovered in assembly 'Gators3' referencing startup type 'Gators3.Startup' conflicts with the attribute in assembly 'MyFirstProject2' referencing startup type 'MyFirstProject2.Startup' because they have the same FriendlyName ''. Remove or rename one of the attributes, or reference the desired type directly.
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.
I tried searching the entire solution for the string "MyFirstProject2" but did not come up with anything. The message gives a couple of suggestions, but none of them mean anything to me. I don't know how to "Remove or rename one of the attributes, or reference the desired type directly," and I don't see a place in the web.config to "add the appSetting owin:AppStartup with the fully qualified startup class or configuration method name in your web.config."
I found this, but am not quite sure how to implement it. I also did find [assembly: OwinStartupAttribute(typeof(Gators3.Startup))] in my Startup.cs, but not sure what the right thing to do there is either.
The problem is that the Gators3.dll and MyFirstProject2.dll are in the same folder (I guess it is bin folder on your server) and both are using Owin middleware. If you do not need MyFirstProject2.dll then the easiest way would be to delete that assembly. If you need it, but without Owin - add following line to Web.config/app.config in your MyFirstProject2 project:
<add key="owin:AutomaticAppStartup" value="False" />
If you need to use Owin for two projects configure friendly names for both of them.
Gators3 project:
Change Owin startup attribute to something like:
attribute [assembly: OwinStartupAttribute("GatorsConfig", typeof(Gators3.Startup))]
And add following line to Web.config within appSettings section:
<add key="owin:appStartup" value="GatorsConfig" />
MyFirstProject2 project:
Change Owin startup attribute to something
like:
attribute [assembly: OwinStartupAttribute("MyFirstProject2Config", typeof(MyFirstProject2.Startup))]
And add following line to Web.config within appSettings section:
<add key="owin:appStartup" value="MyFirstProject2Config" />
I had the same issue : removing everything in the /bin folder and rebuilding the solution alone worked for me. But it could be combined with renaming your assembly attribute at the top of the startupclass, giving it a Firendly name which will help to differentiate both the startup files.
[assembly: OwinStartup("MyFriendlyNameForProject1",typeof(MyProject.Startup))]
Clear your bin folder and obj folder.Rebuild the project again and run :)
Also, if you publish a solution to Azure:
1) right click and select Publish.
2) go to Settings and expand the "File Publish Options"
3) select "Remove additional files at destination"
4) Publish
Worked for me, after deleting the files from obj and bin Folder.
Delete anything that says 'MyFirstProject2' from your bin folder and rebuild the solution, It will work.
Happens when you reference (by mistake?) a project with owin startup inside another project with owin startup. Fix - delete the reference, bin, obj folders and rebuild.
I had the same problem and i added the following tag on web config:
<appSettings>
<add key="owin:AutomaticAppStartup" value="false" />
</appSettings>
This is what I have done:
Since I have 3 projects in one solution, I had to open all bin folder of each project and delete all files there.
Build each project one by one.
Build the whole solution.
Problem solves on my part.
Remove all files in your 'bin' folder and rebuild.
Delete files Bin, Build each project one by one.
Deleted everything in the bin folder, including the roslyn folder then published, and everything worked fine.
Remove old built data in temporary files, in the following path
C:\Users\[user]\AppData\Local\Temp\Temporary ASP.NET Files\vs
In my case, I was referencing one project in the other accidentally, which is why I was getting this error after removing the one accidentally added in the main project solved the problem.
When I run my application it's throwing an error and highlighting this line in the web.config:
<add namespace="Telerik.Reporting" />
When I look at the references for my project, I can see that it's there and it's path is:
C:\Program Files (x86)\Telerik\Reporting Q3 2014\Bin\Telerik.Reporting.dll
In my controller, I can put using Telerik.ReportViewer.Mvc; and there's no problem. But when I try to reference it from my razor view it can't find it, and as mentioned above if I try to add the namespace from the web.config I get an error.
What am I missing here?
I had to set copy local to true for the references I had this issue with. I'm not sure if that's normal or if it's something special to do with the telerik assemblies though.
I am getting error when i am publish my ASP.NET Application in localhost using IIS 7.5.
all the pages run perfectly expect on and getting error:-
Compiler Error Message: CS0433: The type 'pages_Default' exists in
both'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET
Files\root\785050d7\543e65af\assembly\dl3\6a3d3e87\242bc946_6834cf01\App_Web_zxwcuztt.DLL'
and 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET
Files\root\785050d7\543e65af\assembly\dl3\c72e1cad\7d5dd447_6834cf01\App_Web_b5bhtyqt.DLL
Plese Help me to resolve this
Try it:
I set the batch="false" attribute on the compilation section in web.config worked for me.
This tells ASP.NET to dynamically compile individual .aspx/.ascx files into separate assemblies. This avoids the circular reference issue that triggers the exception.
<configuration>
<system.web>
<compilation debug="false" batch="false"></compilation>
</system.web>
</configuration>
Or
You will have a path similar to the following:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Delete the contents of this entire folder (no harm will be done), then try and Clean and Rebuild your solution.
Or
The problem occurred in a virtual application's bin folder. Looking into this bin-folder you will probably see two files (an information i found here):
App_global.asax.dll
App_global.asax.compiled
Removing these resolves the error. The App_global.asax.dll is generated at runtime too which causes the problem.
I am however still investigating how these files got there, so comments are definitely welcome!
We have a whole bunch of websites with very similar web.config files.
Can you centralise the duplicate configs in 1 config file before the root directory of each website? Or is the only option machine.config?
We are looking to centralise an assembly reference in the GAC.
Structure:
Containing Directory
Website 1 Directory
Website 2 Directory
Website 3 Directory
Web.Config File for all above sites
I have not encountered a way to have inherited config files besides machine.config, app/web.config and user.config levels. But you can use configSource attribute on all config sections (ConfigurationSection based) to include a common file for example with service endpoints, client endpoints, bindings, connection strings and others. Even though VS intellisense marks it as unsupported it does work.
<configuration>
<system.serviceModel>
<services configSource="Services.config" />
<client configSource="Client.config" />
<bindings configSource="Bindings.config" />
<behaviors configSource="Behaviors.config" />
</system.serviceModel>
<pages configSource="pages.config"/>
</configuration>
Config source files must be in application's folder or any folder below. No going up or absolute paths. But there is a trick to overcome this limitation in VS2010. You need to add an existing file as a link and change its property named "Copy to Output Directory". This way your absolute path file will get copied to your application folder from where you can reference it in configSource.
In previous versions of VS it is also possible but in a less elegant way - copy file in post build event.
If you are looking mainly to centralize WCF settings there is another option: in-code configuration. Huge advantage of this is you get compilation-time check and refactoring support from VS. If this does not sound like much I can assure you that in a bigger WCF project, config file management is a nightmare especially when you need to change something. With this approach it is also very easy to centralize WCF settings by just creating a common assembly where all services, endpoints, bindings etc. are defined. Disadvantage is that you loose possibility to change WCF settings without recompilation. But if those settings do not change very often it is a tempting alternative.
You can use the web.config located in
%SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\Web.config
Or if in IIS you configure your Containing directory as a main web site and then put your website directories as applications, you can put the web.config in the main web site to have the structure you mention.
I have a type in my App_Code folder from a Web Site project that I want to refer to in Web.config. The type attribute is requiring me to put in an assembly name. The internets is failing me with what to put in for the assembly.
Specifically in,
<system.web>
<webServices>
<soapExtensionReflectorTypes>
<add type="MyType, $App_Code$" />
</soapExtensionReflectorTypes>
</webServices>
</system.web>
What do I put in $App_Code$ to make it compile? I've tried _ _ code, App _code, App _Code (Markdown is failing here: those type names don't have spaces in them)
OK, I found the answer on some obscure MSDN forum: you can't do that in a Web Site project for system.web/webservices/soapExtensionReflectorTypes. Only a Web Application Project will suffice.
I found a work around for a Web Site project. I moved the type out of the App_Code folder and put it in a new class library, compiled and added to the bin directory.
Now the web.config section finds the type through
<soapExtensionReflectorTypes>
<add type="MyNamespace.MyType, FileTitleOfLibrary"/>
</soapExtensionReflectorTypes>
The second argument is the filename of the library without the file extension.