I am part of a team working on a large application. I am a new addition to this team and am building a new piece of the app. As part of this process, I've created a WebApi application that will expose some HTTP endpoints through which I will retrieve information about the app.
Due to conditions it would take far too long to explain, I'd like to get the WebApi project to build in another directory, specifically ..\bin\Server\Debug\ as this is where most of the other portions of the app build to. I would not bother except that the app tried to use files that are found based on the working directory which is currently wrong for my WebApi app.
I tried changing it in the project settings and now I get this error:
My Googling has turned up little help thus far. Anyone know how to resolve this?
Try adding a runtime probing path in the configuration:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin\server\Debug;"/>
</assemblyBinding>
</runtime>
</configuration>
In addition to above step and to get rid of globa.asax error. Open the mark up of Global.asax file and Add follow line on the top.
<%# Assembly Name="<you_web_app_assembly_name_here>" %>
Now you'll start getting the error of System.web or BindingProvider not found etc. There's weird fix for it start adding assemblies to assembly tag under compilation.
<compilation debug="true" targetFramework="4.5" optimizeCompilations="false">
<assemblies>
<add assembly="Microsoft.AspNet.Identity.Core, Version=2.2.1, PublicKeyToken=31bf3856ad364e35" />
<add assembly="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Optimization, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</assemblies>
</compilation>
You'll get few more errors like this but this will get you going.
Reason: The problem I see is that there's an option to change the output path but Asp.net does on the fly compilation. Which why the error are compilation related when you try to run the website. Somewhere the run time compilation only look in \bin folder and which is why we have to specify every assembly that the project is referencing to.
Update -
Unfortunately you can not change the bin directory. After looking at all options and digging found that bin folder of Asp.net web project is not ordinary binary output folder. It's a share code folder from where the binaries are referenced directly in the project.
The binaries are compiled when a first request is received by webserver for Asp.net application. And bin folder is only use as shared binary references folder and not the actual output folder/directory.
The actual output folder of On-the-fly compilation in Asp.net is default set to %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\Temporary ASP.NET Files that you can change ofcourse from compilation tag attribute [tempDirectory][3] in your web.config.
After all these research I came to this conclusion that the option for changing the directory from project -> properties -> Build -> Bin is appearing because of Asp.net website project template. This gives the user same look'n feel as any other project. But the functionality of asp.net website remains the same. The Bin folder still works as it used to work in old website template of Asp.net.
You cannot change the output directory of an asp.net application due to IIS security restrictions, this is why it is not working.
If you are trying to manage dlls due to DI, copy all other satellite dlls into bin folder of your main asp.net app
You can try copying the dll with the after build target. First change the output path back to what it was if you changed it before. Then add some code like this in your project file.
<target name="AfterBuild">
<copy destinationfolder="..\bin\Server\Debug\" overwritereadonlyfiles="true" sourcefiles="$(OutputPath)\$(AssemblyName).dll" />
<copy destinationfolder="..\bin\Server\Debug\" overwritereadonlyfiles="true" sourcefiles="$(OutputPath)\$(AssemblyName).pdb" />
<copy destinationfolder="..\bin\Server\Debug\" overwritereadonlyfiles="true" sourcefiles="$(OutputPath)\$(AssemblyName).xml" />
</target>
This will put the built dll in to the folder specified in destinationfolder. I usually use this for class libraries but i don't see why it would not work for a web api project
You can check out my blog post on this if you like.
http://torontoprogrammers.blogspot.com/2014/11/msbuild-targets-and-tasks.html
Related
In my web application we are using HTTP modules, this module has been registered as follows:
<system.webServer>
<modules>
<add name="MyModule" type="com.Security.MyModule, MyModule, version=1.0.5873.52018, culture= neutral, PublicKeyToken=fegg50b0f0f4" preCondition="managedHandler" />
<modules>
<system.webServer>
I want to edit the functionality of this module, where can I find the physical path of the above module.
Note: There is no assembly reference made for this module in the web application. The above Registration code in the Web.config file is the only link between the module and application.
I would search in the local directory, the bin and in the GAC. More information on assembly loading can be found here.... You may also like to try Fuslogvw.
I have a new .Net 4.5.2 (checked that this is the target framework) Web API Application (in VS 2015). I have referenced System.Net.Http, and as you can see the version is 4.0.0.0:
In my Filter/Attribute I am trying to reference HttpRequestMessage which is in the System.Net.Http namespace (I have the correct using at the top of my file), yet am getting the message that
The type 'HttpRequestMessage' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
And although I can't reference that class, I can browse to it in the Object Exploerer (I assume this uses the .xml file of the same name next to the .dll).
I have tried (edit: as well as the usual restarting VS and rebuilds etc):
Removing and re-adding the reference (from both the Framework and
Extensions - although I'm certain it's meant to be the Framework version, I was getting desparate)
Installing from Nuget and referencing the version in my
local packages folder, which seemed to just default back to the system-wide version.
Reinstalling all my dependencies in Nuget PM with: update-package -reinstall -ignoreDependencies
Adding the assembly manually to the web.config Adding the assembly manually to the .csproj file
[Edit: Solution:
OK, I created a few new VS Web API projects (and solutions) to see if I could reproduce the problem. In the end I created a new "Filters" folder, created a new Filter class in there, copied the contents of my pared-down original over, and lo-and-behold HttpRequestMessage was recognised. Did the same thing going back the other way (my filter was originally created in an App_Code folder) and it was still working. I think perhaps there was an unseen reference to an old System.Net.Http that was throwing a spanner in the works and even though I may have commented out the code that called it, somehow it was being remembered. That's just a guess. But anyway, paring it down to barest bones and going from there was the final approach that led to a solution.]
In my case, willing to actually use dynamically compiled files inside the App_Code, I had to add explicitly the assembly in the compilation node of the Web.Config:
<system.web>
<compilation targetFramework="4.8">
<assemblies>
<add assembly="System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</assemblies>
</compilation>
...
This solved my case. Of course, adjust the target framework according to your project needs.
I also managed to resolve this by moving my custom RouteConstraints out of the App_Code folder. Just added a new folder to my project and copied them there.
I've tried this highly suggested solution (on Web.Config)
<system.web>
<compilation debug="true" targetFramework="4.5" />
<compilation debug="true" targetFramework="4.0">
<assemblies>
<add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</assemblies>
</compilation>
</system.web>
But unfortunately, this didn't work me. At last, I've found a solution (this worked for me)
Right-click the References folder > Add Reference...
Expand Assemblies on the left side of the window and select Framework.
Scroll to and select System.Net.Http in the list of assemblies.
Make sure the box next to System.Net.Http is checked, then click OK.
Rebuild the project.
If you're coming from creating web sites, but are now creating a web application, don't add the App_Code folder or any code into it as each class file will either be set to "Content" (click on the class, look in the Properties pane under "Build Action") and so won't be picked up by Intellisense in the rest of the application, or you can set to "Compile" but then that has its own problems at release time: See Vishel Joshi's blog all about it.
I am having the same problem, (which is how I stumbled on this question) and there is one thing that I noticed that nobody seems to have latched onto yet.
I am building a WebApi2 application, and I added in a class library to turn into an nunit test library. I started getting conflicts with System.Web.Http. It appears that the webapi2 uses 5.2.6.0, where other things will try to default to 4.0.0.0.
Make sure that you are using the correct version of System.Web.Http, and that you also have the System.Net.Http assembly referenced. Once both assemblies were referenced and running the same version numbers across all solutions, all problems were resolved. VS doesn't always load the correct versions by itself.
I'm having an issue where I keep getting error message CS0246 on my web server, but not in my visual studio environment. The issue is coming from a dll I reference in my project. The server cannot find my namespace for my dll.
To solve this I tried copying every file in my project directory to my web server, adding a tag in my web.config file, and adding an import statement in my aspx page. I have also tried adding an assembly reference in my aspx page, but that seems to require a change in the registry which I don't think I have access to.
I should also note my dll and namespace name are different, but changing the names of either did nothing. I also completely removed the dll and copied the code files directly into my project, but it still could not find the namespace.
I thus think I'm supposed to register the namespace and dll somewhere else, but I cannot figure out where. Any help will be appreciated.
If it matters, both my web project and dll are using .NET2.0
I know this is the equivalent of the annoying "did you reboot", but have you tried making a new solution and re-adding the projects and references? Sometimes the .sln file can get corrupted.
Sometimes, the web.config file contains instructions for the .NET framework to generate temporary files.
Please check your config file for something similar to:
<system.web.webPages.razor>
<host
factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<pages pageBaseType="System.Web.Mvc.WebViewPage">
<namespaces>
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="YourNamespace.ShouldBeCorrect.Here" />
</namespaces>
</pages>
</system.web.webPages.razor>
This is likely the case if your error page contains a reference to a dynamically generated file such as:
Source File: c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\133f2363\4ba6d0ba\App_Web_index.cshtml.a8d08dba.ociepbng.0.cs Line: 27
I'm trying to use System.DirectoryServices in a web site project and I'm getting this error:
The type or namespace name 'DirectoryServices' does not exist in the namespace 'System' (are you missing an assembly reference?)
My project has a reference to System.DirectoryServices in web.config:
<add assembly="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
And I do have using System.DirectoryServices in the files where I want to use it.
Does anybody have a clue where to look for the problem?
Right click on References under your solution.
Select Add Reference.
The reference can be found under the Framework Assemblies list.
Select System.DirectoryServices and click Add.
I think you should install Directory Services Package.
Install-Package System.DirectoryServices -Version 4.0.0
Directory Services Package
Shot in the dark: have you tried adding to the web.config:
<compilation debug="true">
<assemblies>
<add assembly="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
</assemblies>
</compilation>
Is the web-server (IIS or whatever) configured to run the folder as an application (i.e. shows as a cog), and is it using the correct version of ASP.NET? If it is running as 1.1, bits of it might work - but it would fail to find that 2.0 assembly in the 1.1 GAC.
This is a very old thread but just to provide a complete answer for the sake of posterity ;)
This issue occurs if the project is missing a reference to the .Net Component System.DirectoryServices
Adding this reference in the usual manner prefered by you will resolve the issue.
Is this a web site project, or a web application project. With the latter, references are handled via the .csproj - i.e. via the "References" node in Solution Explorer.
On Solution Explorer right-click your project, then from the resulting menu, click on Add Reference, then under the .NET tab navigate to DirectoryServices.AccountManagement
These problems occur when you are working with older .net version and trying to build with the latest IDE
It depends on which version of IDE you are using and also the current code version.
Check the web config,
In my case, I was using the Latest version i.e 4.7 and directoryService assembly are still referring to C#4.0.
Add below if you are using Latest version of id i.e 4.7
<system.web>
<location>
<compilation debug="false" numRecompilesBeforeAppRestart="100" targetFramework="4.7">
<assemblies>
<add assembly="System.DirectoryServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="System.DirectoryServices.AccountManagement, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
</assemblies>
</compilation>
</system.web>
</location>
I had the same problem when I tried to convert website to web-app.
It looks like vs failing to load the assembly should be related to versioning.
switch to web.config and add the assembly to it as bellow. make sure the DLL version is matching your application targeted .NET version.
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0">
<assemblies>
<add assembly="System.DirectoryServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</assemblies>
</compilation>
</system.web>
</configuration>
for getting a public key you need to launch Developer Command Prompt for VS. Change to GAC directory related framework on above ex C:\Windows\Microsoft.NET\Framework\v4.0.30319
and call
sn -T System.DirectoryServices.dll
I've registered a control in my web.config file and the .dll for the control has been placed in the application's Bin folder.
<compilation debug="true">
<assemblies>
<add assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="RichTextEditor"/>
</assemblies>
</compilation>
<pages>
<controls>
<add assembly="RichTextEditor" namespace="RichTextEditor" tagPrefix="cc1" />
</controls>
</pages>
I can now use this control in .aspx pages in the application root folder without issue. However, some of the .aspx pages I want to use this control in are stored in a sub-folder of the application (In this case a sub-folder called "Admin"). When I try to use these controls in these pages and run in debug I get an error of:
Error 1 Unknown server tag 'cc1:RichTextEditor'. N:\IntranetV2\admin\EditMenuItem.aspx 27
I'm sure I'm missing something simple here but I can't seem to figure out how to get this working and googling doesn't seem to have helped much.
UPDATE:
Okay I've tried Aaron's solution with no luck, I amended his code suggestion to:
<add tagPrefix="cc1" tagName="RichTextEditor" src="~/Bin/RichTextEditor.dll" />
I hoped this would be all that's required however I now get the error:
Error 1 There is no build provider registered for the extension '.dll'. You can register one in the <compilation><buildProviders> section in machine.config or web.config. Make sure is has a BuildProviderAppliesToAttribute attribute which includes the value 'Web' or 'All'.
Please can someone help! I know the answer to this must be ridiculously simple but I'm going mad trying to fix it myself and google has proved no help.
I had some similar problems a while back. Only way I was able to get the control working was something like this:
<add tagPrefix="cc1" tagName="RichTextEditor" src="~/controls/richtexteditor.ascx">
rather than this:
<add assembly="RichTextEditor" namespace="RichTextEditor" tagPrefix="cc1" />
EDIT:
Since you're using a binary, add the .dll to your solution, and add a reference to it in the project where you're using it. This way, .NET will add the .dll to your bin folder. Then, go back to this (and verify that the namespace and assembly are correct):
<add assembly="RichTextEditor" namespace="RichTextEditor" tagPrefix="cc1" />
Also, check this out as a reference: Tip/Trick: How to Register User Controls and Custom Controls in Web.config
Is the folder defined as an application in IIS? That would cause such a problem since in that case IIS will look for web.config (as well as bin/ and other special files and folders) inside that subfolder.