Every time i build, or publish, a web-site, Visual Studio attempts to check out the web.config file so that it can add numerous assemblies that are not required.
In other words:
web.config before:
<configuration>
<system.web>
<compilation>
<assemblies>
</assemblies>
</compilation>
</system.web>
</configuration>
web.config after:
<configuration>
<system.web>
<compilation>
<assemblies>
<add assembly="Microsoft.ReportViewer.Common... />
<add assembly="Microsoft.ReportViewer.WinForms... />
<add assembly="System.DirectoryServices... />
<add assembly="System.Windows.Forms... />
<add assembly="ADODB... />
<add assembly="System.Management... />
<add assembly="System.Data.OracleClient... />
<add assembly="Microsoft.Build.Utilities... />
<add assembly="Microsoft.ReportViewer.ProcessingObjectModel... />
<add assembly="System.Design... />
<add assembly="Microsoft.Build.Framework... />
</assemblies>
</compilation>
</system.web>
</configuration>
None of these assemblies are required, and most don't exist on the target test, or production, servers.
i keep deleting them every time i build, but it's getting real annoying real fast.
Right now my workaround is to leave web.config read-only - so Visual Studio cannot add assemblies to it.
Update
Screenshots as proof:
Project Property Pages before:
Web.Config before:
Project Property Pages after:
Web.config after:
Update Two
It should be pointed out explicitly that the web-site works without these extraneous references being added. My interim solution is to keep web.config read-only, and hit Cancel whenever Visual Studio complains that it's read-only as it tries to modify it. If i can just stop Visual Studio from trying to modify it in the first place...
Update Three
It looks like it's not possible. Someone can feel free to give the correct answer, "You cannot stop Visual Studio from adding assemblies to your web.config." and i'll mark it.
The only reason i'm keeping the question up is that hopefully someone knows the super-secret option, or registry key, or project or solution setting, to tell Visual Studio to stop thinking.
Update Four
i didn't accept the accepted answer, and i'd unaccept it if i could. i'm still hoping for the panacea. But right now i'm leaning towards:
Answer: cannot be done (manu08)
Workaround: filtered GAC assemblies registry key (Nebakanezer)
How do i stop Visual Studio from adding assemblies to my web.config?
References
ASP Net - Visual Studio keeps adding Oracle assemblies to web.config
Why are the Visual Studio Add-In Assemblies being added to my web.config?
Visual Studio Adds Assembly Reference To web.config
removing VsWebSite.Interop Assembly from Web.Config
Visual Studio 2005 automatically adding references to web.config on build
Maybe the "Avatar DotNet Library" is referencing those assemblies by itself.
The references of a referenced assembly are needed to correctly deploy a project.
Otherwise, how could the referenced assembly work?
Note that it's possible that your referenced assembly does not use its own references, although they exists.
Edit: You can use the great tool ".Net Reflector" to check this.
I used VS2005 to edit a .net 1.1 (VS2003) .aspx and saved it, then the web.config will mysteriously have the net. 2.0 assemblies added:
If I used VS2008 or VS2010, this does not happen. So I believe this is is a bug in the VS2005 IDE.
I had this problem with Visual Studio 2005 (but I'm happy to report that the solution works for VS 2008, see bolded text below). There is a registry section that VS checks before it adds assemblies to the web.config file.
Here is the key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Projects\{E24C65DC-7377-472B-9ABA-BC803B73C61A}\FilteredGACReferences
So, let's say you don't want Visual Studio to add the Microsoft.VisualStudio.Designer.Interfaces assembly to your web.config. Add the following entry to your registry and you are set.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Projects\{E24C65DC-7377-472B-9ABA-BC803B73C61A}\FilteredGACReferences\Microsoft.VisualStudio.Designer.Interfaces
It worked perfectly for me. And yes, the rest of your team will have to do the same, but at least you don't have to manually remove the entries every time :)
To make it work for VS 2008 - just change the 8.0 in the registry path to 9.0
Convert you "Web Site" project to a "Web Application" project.
A "Web Site" does not have a project file, so it contains all assembly references in the web.config. A "Web Project" has a project file, and all references are stored in the project file.
Remove the References.
If it is a web app: you can see the References under Solution Explorer.
If it's a website: right-click the project on Solution Explorer then select Property Pages. Manage them there.
HTH
If a shared assembly references them, then they will be added to the calling project as well.
Since the Avatar library makes these other references, Visual Studio adds these references to the main project as well. Otherwise, a call into the Avatar library could fail since the reference it needs is missing.
Well this might seem like a hack but given your requirements another option would be to load the Avatar assembly dynamically using Assembly.Load or LoadFrom at runtime. This would keep a reference out of the main project and should then prevent the extra reference lines in the web.config. This would only really be practical though if you were only using a small number of classes from the Avatar project. I would make a third project that both projects referenced that held interfaces that one or more Avatar classes implemented in order for the main project to maintain strict typing when handling Avatar instances. I admit this could be a lot more work that previously submitted answers. If your interested in this method search google for creating plugins in .Net
As long as you are using a website, rather than a webapp, I don't know of any way to stop Visual Studio from adding assemblies to your web.config. This same problem of sorts happens for my company's solutions as well.
You cannot stop Visual Studio from adding assemblies to your web.config.
Sorry, you cannot stop Visual Studio from adding assemblies to your web.config, but all is not lost.
I have hit this in the past; someone had added some references (including WinForms) to a low level data access assembly. The web-site used the low level data access assembly and therefore had WinForms etc added to the web.config file.
The solution was to move his code into the correct assembly and remove the incorrect reference.
If you can not sort how the assembly that has the unwanted references and you know you are not calling code that depends on the unwanted references. Then you can (none of these are nice)
Write a custom install action that automates the removal of these unwanted assembly references from the web.config
Write a custom MSBUILD action to remove then at the time of the build
Use a different hand-written web.config file when the application is installed.
It can take ages to find how why Visual Studio is adding a reference to the web.config file. You have to hand-check EVERY assembly that is used directly or indirection by the web site.
I know and appreciate why Microsoft invented Web Sites in ASP.NET 2.0, but sometimes they just plain suck. If it is practical for you, convert your site to a Web Application Project, and problems like this will go away.
If that is not practical for you, try to re-factor as much code as possible into a separate class library project. Any references you can move out of the web site and into the class library will cut down on web.config changes.
EDIT: To clarify, in a Web Site, the aspnet compiler compiles everything (markup, code-behind, the lot), so all assembly references must go into web.config. However, in a Web Application Project, the C# or VB compiler compiles the code-behind files into a separate DLL, which is then referenced by the aspnet compiler when it compiles the markup. In this scenario, assemblies that are only referenced in code-behind files will go into the code-behind DLL and not touch web.config at all. Only assemblies that are directly referenced in markup will go into web.config.
I don't believe you can prevent Visual Studio from automatically adding references to assemblies that are referenced by others.
One solution is to create a Web Setup project with a custom action that automates
the removal of these unwanted assembly references from the web.config.
Those are all the assemblies required by your project, in some shape or manor and the aid the compilation that ASP.NET does on your pages at runtime. They are probably being imported in by either by code you are using in your project or another library that is using them.
But according to the documentation. These are the assemblies defined in your global web.config which can be found in C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG:
<assemblies>
<add assembly="mscorlib" />
<add assembly="System, ..." />
<add assembly="System.Configuration, ..." />
<add assembly="System.Web, ..." />
<add assembly="System.Data, ..." />
<add assembly="System.Web.Services, ..." />
<add assembly="System.Xml, ..." />
<add assembly="System.Drawing, ..." />
<add assembly="System.EnterpriseServices, ..." />
<add assembly="System.Web.Mobile, ..." />
<add assembly="*" />
</assemblies>
If you look there is an assembly="*" reference being added. And if you read the documentation about this command it says:
Optionally, you can specify the
asterisk (*) wildcard character to add
every assembly within the private
assembly cache for the application,
which is located either in the \bin
subdirectory of an application or in
the.NET Framework installation
directory
(%systemroot%\Microsoft.NET\Framework\version).
This means that any assembly in your /bin directory or in the .NET Framework installation directory is going to be included already.
What this tells me about your problem is that those assemblies that are being included are already referenced in some way to your project. And they are probably coming from the Avatar Dot Net Library or some controls on your page. Check the "References" folder in your Visual Studio project on the Avatar Library for these references you don't want. Because that is where the build process gets these libraries from.
So in other words if you don't want them to be included scrub your referenced projects of all references of these libraries.
Alternatively you can use a MSBuild XML parser to drop that section of the web.config each time you run your build process. Personally I use a task called XmlUpdate to modify certain parts of my web.config to get it production ready. If you would like to do the same it is part of the MSBuild Community Tasks.
If you are running on a vista or server 08 machine, you can use the appcmd command line utility to remove it after rebuilding rather than manually removing it.
http://technet.microsoft.com/en-us/library/cc772200(WS.10).aspx
http://learn.iis.net/page.aspx/114/getting-started-with-appcmdexe/
see http://msdn.microsoft.com/en-us/library/ms178728.aspx
there it's explained that what you see in Property Page is not all, implicit references exist also in Machine.config file and are added at compile time. Hope this helps.
I would start by checking the "using" statments in your code files as well as any references in your .aspx, .ascx files. It sounds like you've referenced some of these (I know some are added by default from the Add New Item templates.
Related
I have an extension to VS that should use Gmail api to send mails to certain users in my company.
During development I step into a common issue with System.Net.Http.Primitives version that is somehow messed up in Google API.
The common solution for this is to put bindingRedirect in app.config to redirectall calls to a new up-to-date version of the library. Like below:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.10.0" newVersion="4.0.10.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
However, this seems not to work in case when my output is a Vsix package. Generated Vsix doesn't even have an app.config.
I'm aware of a solution that says to add bindingRedirect to machine.config file but my extensions is used by some other people and I would rather not force them to put stuff into their machine configuration files.
Is there another solution for this?
This was answered over a year ago, but I found a better way to do it by using ProvideBindingRedirectionAttribute. This will add the binding redirects to devenv, and also determine the correct version. Details can be found here, but the relevant part here:
By using the ProvideBindingRedirection attribute, you can specify binding redirection for the installation of an upgrade to an extensible component. When you ship an extensible Visual Studio component, this attribute prevents users of the component from having to install an old version of a dependent component. If you use the ProvideBindingRedirection attribute, you don't need to manually update the exe.config file to redirect users of the old assembly version to the new version.
Adding a ProvideBindingRedirection assembly attribute is an easy way to add a binding redirection entry to the pkgdef file. The pkgdef file is used to install the extension.
The following example shows a ProvideBindingRedirection entry in the AssemblyInfo.cs or AssemblyInfo.vb file:
[assembly: ProvideBindingRedirection(AssemblyName = "ClassLibrary1",
NewVersion = "3.0.0.0", OldVersionLowerBound = "1.0.0.0",
OldVersionUpperBound = "2.0.0.0")]
Technically, the app.config belongs to the process (.exe), not to the dlls. For Visual Studio, it is the devenv.exe.config file located at C:\Program Files (x86)\Microsoft Visual Studio <version>\Common7\IDE.
But to modify that file your extension should be installed with admin rights (that is, .msi or similar installer technology). And I don't think it's a good idea to modify that file since it would affect other extensions.
One approach that you can try is to redirect binding by code somehow forcing an assembly resolution failure, subscribing to the AppDomain.AssemblyResolveEvent, to get a chance of providing the exact assembly that you want. See: http://blog.slaks.net/2013-12-25/redirecting-assembly-loads-at-runtime/
Nice info, this ProvideBindingRedirection. It however affects the Visual Studio configuration, not just the VSIX. In particular our VSIX requires redirects for NuGet assemblies, causing the package restore support in Visual Studio to fail...
I somehow brought my project to a state where Visual Studio 2013 fails to compile it with a ridiculous error:
The type 'System.Collections.Generic.Dictionary`2' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Collections, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
First of all, there is no such assembly, it does not exist.
Second, Dictionary<TKey, TValue> is defined in mscorlib.dll, which is referenced by default, of course. Resharper (which has its own code analysis engine) reports that the solution should compile normally.
I don't know how on Earth it could happen, because my latest changes have nothing to do with the supposedly erroneous place at all. The line references some standard LINQ functions (GroupBy and ToDictionary), and it worked for months without any changes. Unfortunately, I cannot create any MREs: obviously, this error only appears in the context of my huge solution, and only with some specific changes made in the presumably irrelevant places.
Here's what I tried, and it didn't work:
Clean + Rebuild
Changing target Framework from .NET 4.5 to .NET 4.5.1 or .NET 4.0
Has anyone seen such a quirk before?
I had the same problem, but it was on a website project - not any easy way to remove & re-add the references. Luckily, I found that this answer worked for me - and was even quicker than messing with references
https://stackoverflow.com/a/29575865/3841490
adding a new assembly tag to web.config seems to have resolved this
issue. The tag I added was under the tag and as follows:
<assemblies>
<add assembly="System.Collections, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
I had the exact same issue and it seemed to be related to two NuGet packages containing the same assembly "System.Collections.Immutable". The two NuGet packages where "Microsoft.Bcl.Immutable" (Unlisted) and "System.Collections.Immutable".
I haven't been able to reproduce the issue reliably, and it seems the problem was solved by using VS2015.
However, i would suggest looking for NuGet packages containing the same assembly.
Removing Microsoft.Bcl.Immutables solved this for me.
Check that all the (core .net) references in your project are valid and they all reference the same .NET framework version.
If in doubt, remove all references and add them again (using the 4.0.0.0) versions.
I had this happen to me once (with the exact same error) and it was due to some "screw up" on the version of the references. I never got to find out WHY it happened, but removing all references and adding them again worked for me.
My BizTalk solution has 10 BizTalk projects that are referenced between each other.
In each project's properties I have set redeploy feature to 'true' (it's by default).
But when I try to redeploy the whole solution from VS 2012, I get following errors for some projects in solution:
Error 201 Failed to add resource(s). Change requests failed for some
resources. BizTalkAssemblyResourceManager failed to complete end type
change request. Cannot update assembly "Project1, Version=1.0.0.0,
Culture=neutral" because it is used by assemblies which are not in the
set of assemblies to update. To update the assembly, remove the
following assemblies: Project2, Version=1.0.0.0, Culture=neutral
Project3, Version=1.0.0.0, Culture=neutral Project4, Version=1.0.0.0,
Culture=neutral Project5, Version=1.0.0.0, Culture=neutral Project6,
Version=1.0.0.0, Culture=neutral
As I read from this article:
http://blog.codit.eu/post/2013/07/30/Redeployment-notes-of-a-BizTalk-solution-from-Visual-studio.aspx
In the process of deploying a BizTalk assembly, you first needed to
manually stop, unenlist, and unbind artifacts contained in the
assembly in BizTalk Server and then remove the assembly from the
BizTalk Management (configuration) database before deployment. Visual
Studio will handle all those steps for you with this option Redeploy.
What could be the reason of my problem and possible solution?
Please check if you use subfolders in your solution.
I suggest to create new (additional) solution just for deployment purpose where you should avoid to use any solution subfolders
Andrei
You can try deleting the temp binding files at: C:\Users\%username%\AppData\Roaming\Microsoft\BizTalk Server\Deployment\BindingFiles
Then try again.
Check that one of the assemblies hasn't gone into the Default Application rather than the application you are deploying too. If you find one in the wrong place you can right click it and select Move to Application. (The other option is to remove it, but then quite often you have to remove all the dependent ones as well).
Check each project that the Application is set.
Then re-deploy.
This happens quite often, especially if you just got a project down from source control, as the Application is saved in the user file rather than the project file.
Edit: Also check your solution setting to make sure all projects have deploy ticked.
Check in the configuration manager for solution if any project is not marked for deployment. Right click on solution then select Configuration Manager and make sure all projects are selected for deploy,
Apparently there is some problem with BizTalk 2016 party export/import that prohibits re-import of bindings during deploy from Visual Studio.
My workaround is to export bindings manually before deploy, and manually import bindings after "successful" deploy (cited from the deploy log in visual studio ;).
Other reference:
https://social.msdn.microsoft.com/Forums/en-US/c49758c0-0465-4c13-97a3-300c05d00d3a/biztalk-2016-redeploy-and-orchestration-bindings?forum=biztalkgeneral&prof=required
When I create a new web site project (not web application) in VS 2010, it seems to have some dlls already referenced. If I try to add System, System.Core, System.Data, I get the error stating that "The Web site is already referencing the assembly 'System.Core'" etc. When I try to use a datatype from one of these assemblies, it seems to be recognized and I get intellisense and all. But I cannot see these dlls added in the Web.Config nor when I open the references tabs in the properties of the website. Is there any new secret place that these "Default" references are being added to?
Background Info:
The main reason I am trying to figure out these references is that I have migrated a project from VS 2008 to 2010 and I am getting build errors that System.Data.DatasetExtensions need to be refered. However, the reference is present in the web.config and I can also see the reference in the project properties. I also checked that it has the same version and same public key token as the build error. Below if the build error:
error BC30007: Reference required to assembly 'System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' containing the base class 'System.Data.TypedTableBase`1'. Add one to your project.
Here is the reference in the web.config:
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation debug="false" strict="false" explicit="true">
<assemblies>
<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
<authentication mode="Windows"/>
</system.web>
</configuration>
I would really appreciate if someone can help me figure this out.
Thanks.
Notes:
1. I do not have the option of moving to a Web Application project.
2. In VS 2008, references from GAC were stored in Web.Config, Project references were stored in the solution file and other dll references were stored as .refresh files in the bin folder. I cannot find these dlls in any of the above places.
I had the exact same problem, and I eventually figured out the cause to mine was that I had copied a DLL to the project's BIN folder. Doing this causes Visual Studio to consider the DLL referenced. If you move the DLL outside of that folder, you'll be able to add the reference from within Visual Studio.
My debugger is not working,
I'm putting a breakpoint, but in run, time visual studio doesn't stop on the breakPoint.
How to fix it?
There is nothing special in my application, it is a simple web application.
I am using visual studio 2005.
I've created a new web application project, and on the default.aspx page there is a obout grid control, on the default.cs i am filling a datatable and putting it as datatasource for the grid.
I was able to debug it, suddenly the debugger is never hit.
note that the debugger is on the load event.
Find below the steps that solved my problem:
Delete ASP.NET temporary files from C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
Change build configuration to debug from project properties.
Delete bin folder from your project.
Check if compilation debug is set to true in the web.config
iisreset
Rebuild the project.
There are a couple of things that could be wrong:
Your source code and assembly could be out of sync - rebuild the application and try again.
You could be attached to the wrong process - check to see what process you are attached to.
There could be a logical error in your code that is causing your breakpoint to not be hit (i.e. the method you are in is not actually called, logical branching is routing control around the breakpoint, etc.)
Break point was not getting hit, i cleaned and rebuild, but still not hitting, I just reopened the page (In my case Controller) and started working fine ..
When everything failed try this:
Right mouse button on your project -> Build -> untick 'Optimize code'
Or
I had similar problems when I've installed dotPeek and maybe because I don't have Resharper it was loading symbols from dotPeek symbol server but it couldn't hit my breakpoint. In that case Open dotPeek and click on Stop Symbol Server.
The symbols probably aren't loaded, that's why the breakpoint won't be hit. Did you set the website as the startup project?
When debugging, what process it attached? It should be w3wp.exe if you want to debug asp.net code.
You might need to set your application in web config so that it can be debugged..
<system.web>
<!--
Set compilation debug="true" to insert debugging
symbols into the compiled page. Because this
affects performance, set this value to true only
during development.
-->
<compilation debug="true">
<assemblies>
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
You need to be running in Debug mode, and not Release mode.
Here's a detailed article about How to: Enable Debugging for ASP.NET Applications Basically, you can either set debug mode in project properties or in web.config.
try uncheck "Enable the Visual Studio hosting process"
that in project properties -> debug
worked for me
This can occur when Visual Studio is set to debug Managed code but the code is not managed (managed code is running under the control of the common language runtime (CLR)).
To fix the problem change the debug mode as shown in the right hand side of the figure below to Native only, Mixed, or Auto.
Side note: I recommend not choosing Mixed unless your system has both managed and native code (code that does not run under the CLR) because Visual Studio can't attach to an already running process in mixed mode. To debug an already running code Visual Studio need to be set to debug in Native only or Managed only.
I've seen the already existing answers have listed many possible causes, but I'd like to add one more: if you're using post-compilation tools (such as ILMerge), check whether those tools keep your debugging information (is there a .pdb file? or maybe you have embedded it in your compilation output). For those ones who are actually using AfterBuild tasks in their .csproj I really suggest to check out.
You can enable Debug as below steps.
1) Right click project solution
2) Select Debug( can find left side)
3) select Debug in Configuration dropdown.
Now run your solution. It will hit breakpoint.
Are you debugging using IIS Express instead of IIS Local. I found IIS Express sometime won't hit debug points, IIS Local works fine.
You could be like me to have both a production version (installed via a msi file) and a development version (opened in Visual Studio), and that is why I cannot get some of my breakpoints in the VS triggered today.
If that is the case you need to uninstall the production version as I think some of the dll files are interfering with my debugging session.
Clean and Rebuild your solution afterwards should fix the issue.
if you are using publish and IIS, then check your Publish configuration, make sure it says Debug
Go to publish window
[1]: https://i.stack.imgur.com/X9Dke.png
In Visual Studio 2010
Select Build > Clean {Project Name}
Rebuild Project
Now Try to rebuild project and try debug
All the best
After installing following add-on it started working. After installing, restart visual studio once. Install plug-in as per VS version.
https://download.qt.io/official_releases/vsaddin/