I maintain a ASP.NET WebForms app written by someone else who long since left. Even though the app has about 10 .aspx pages in it, the solution has 12 VB.NET projects. All of the warnings in the build are of this type:
Warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.
I've looked here on SO for help. I came across this post Visual Studio .NET: warning MSB3277: Found conflicts between different versions. However, the answers given referenced NuGet packages. The conflict in this app I maintain is due to one of the 11 other projects within the Visual Studio solution, so I don't believe the answer I found here on SO, applies in this situation.
At first, I thought all I'd have to do was delete the DLLs being created the web application's bin folder. (Not sure why the original developer included the bin folder in the project, but he did.) So, I deleted the DLLs and PDB files, but whenever I build the app, it puts them back into the web application's bin folder. Perhaps that is the way VB.NET (or .NET) works, it just surprises me. Note: the application does build and can be deployed. I've done so. I'd like to get rid of these warnings.
The original developer wrote this using .NET 2. I upgraded it to .NET 4.5.2.
Related
Current Situation:
I have an ASP.NET web project. (Framework Version: .NET Framework 4.5.2)
One developer here is able to compile it and run it fine in Visual Studio 2017.
I cannot, I get the "could not load file or assembly" error for a reference that is in my list of references.
Screenshots:
Error:
Bin Folder:
Web.config Potential Relevant Sections:
DevExpress Licenses File:
DevExpress Library File's Details:
Things I've Tried:
Clean Solution & Rebuild Solution
Deleted solution locally and clean get of solution from source control
Clearing out my temp directory
Opening the project in Visual Studio 2015
Having the developer zip up his local copy of the solution / project and sending it to me (When I ran his copy locally I continued to get the same error.)
Re-adding the existing library it's complaining about
Manually deleting and re-adding all the libraries in my BIN folder
Messing with the license file, web.config, and assembly references in code (including adjusting the version numbers because for some reason the version number is 17.2.5.0 anywhere it's referenced in the project, but the file's Details actually says it's 17.2.9.0?)
Smashing my face into my keyboard...
...Always the same error.
Additional Information
Other developers run into the same exact error under the same conditions as me, only my one developer who's been working in this project can build it fine
I just noticed that on a new copy of the work project, my references window is showing 2 of the same reference to the DevExpress.Data library (one in the GAC and one in the BIN) but when I try re-adding the reference to my project, the one in the BIN disappears from my references window:
The best way to include System.Net.Http.Formatting might be through nuget. But when a developer sees it in the default Assemblies section in reference manager then they just add it, expecting all developers to have it installed by default. But to our surprise, some developer machines did not have this dll.
All developers have the correct folder where this dlls is found
"C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Assemblies\"
Some developers just have XML files and others have dlls in it, even though the file names are the same.
Why are dlls missing in some machines?
Sometimes it is really an issue while finding the missing dlls. Better approach is to clean the nuget cache and folder both and restoring nuget packages again would resolve this issue.
System.Net.Http.Formatting mystery resolved
System.Net.Http.Formatting won't be installed by default along with asp.net. If it appeared in one developer machine, then it could be because some other projects in the VS might have used a nuget to pull it in. This developer without knowing this gives a manual reference to this dll in a new/different project. To him/her everything works fine.
When another/new developer comes and tries to do the same in his/her machine, before reaching this particular project(which pulled in System.Net.Http.Formatting through nuget), the developer gets error(from the manually entered dll project by the previous developer mentioned above). That explains why the dll is missing in his/her machine.
But why is XML file present then?
Becuase the package folder was stored in tfs/git from the first developer machine(who successfully had the dll through nuget). And tfs/git ignored the dll when checked-in.
There has been a lot of talk about the C# compiler Roslyn on StackOverflow and the internet in general. A lot of people ask what and why with Roslyn, while others ask how to get rid of it.
My question pertains to the latter question. As quoted from Kemal Kefeli from here, but frequently iterated verbatim by dozens more (e.g. another example of iteration), in order to remove Roslyn:
When you create a new web project, two NuGet packages automatically added to your project. If you remove them, your problem should be solved. Package names are: "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" and "Microsoft.Net.Compilers".
This approach, however, does not work if you are using the C# 6 features that Roslyn offers. By removing these two nugget packages, you give up any chance of using these features.
My question is, how do you compiler everything with Roslyn, but avoid having any compiler-at-runtime actions occurring and most importantly, the csc.exe, vbc.exe, and VBCSCompiler.exe from being placed in the final release version (in the Roslyn folder).
I am porting over StackOverflow's Opserver into a piece of software. The software allows users to host embedded web servers and web pages from within it. However, the software is very picky about what it allows to be uploaded and executables, like those found in the Roslyn folder, are not allowed to be uploaded and executed at runtime due to security reasons.
Opserver relies on C# 6 features, because if I remove those two NuGet packages, errors sprout up in compile-generated files. But, if I more simply revert to compile strictly with the C#5.0 compiler, then we see this clearly:
If I leave the NuGet packages present and uncheck allow precompiled site to be updatable when publishing, in order to disallow Roslyn with compiling files at runtime as followed by Rutix's comment from here:
Keep in mind that removing these packages [as told by Kemal Kefeli] will break the use of C# 6 features. This could be solved by unchecking "Allow precompiled site to be updatable" which pre-compiles the views ect.
It still generates the executables and the associated DLLs in the Roslyn folder, however significantly less DLLs. How can I possibly remove the Roslyn dependency at runtime and therefore the executables from the outputted version and strictly compile everything at compile-time?
In fully precompiled ASP.NET project ("allow precompiled site to be updatable" disabled) there is no need for compiler to be deployed with app IMHO.
I'm using Roslyn in my .NET 4.6 ASP.NET app (mix of Web Forms and MVC) and precompiled app works just fine after removing Roslyn folder\files from published site...
UPDATE: After a while a found only place where absence of Roslyn in deployment package is the problem a that's accessing ASMX (old style ASP.NET SOAP web service) in browser - "help" page for ASMX is apparently build at runtime even for fully precompiled ASP.NET application and it throws exception (although WS itself runs OK)
I'm using Visual Studio 2013 and MvvmCross to create an Android application using Portable Class Libraries.
I notice in my first view model, CatalogViewModel, some code is highlighted as not referencing the correct assemblies or unable to be resolved (the code builds fine even with these issues).
Examining the .NET Portable Subset assembly in the Object Browser shows various System assemblies included (2.0.5.0 v2.0.50727 & v4.0.30319, 4.0.0.0, 5.0.5.0). Automatic binding redirection for assemblies in .NET Framework 4.5.1 can be enabled or disabled by adding this line to the .csproj file.
<AutoGenerateBindingRedirect>true</AutoGenerateBindingRedirect>
or
<AutoGenerateBindingRedirect>false</AutoGenerateBindingRedirect>
This seems to solve the referencing and redirection issues in the IDE. I haven't found any information about this manual modification to the Core project file in any of the MvvmCross info online I reviewed so I wanted to post a question here to see if anyone had some information or best practices.
No, you shouldn't need AutoGenerateBindingRedirect. This feature is intended to generate binding redirects for non-platform assemblies, such as NuGet packages. Platform assemblies should be unified automatically by Visual Studio / MSBuild.
Which seems to work, since you pointed out:
the code builds fine even with these issues
So this looks like a bug in ReSharper. The fact that adding AutoGenerateBindingRedirect fixes your ReSharper issues might be a side effect of something else.
I am getting a build error when I attempt to build my asp.net application. The error is:
The type 'MediCare.Framework.Authentication.IUserAuthenticate' is defined in an assembly that is not referenced. You must add a reference to assembly 'MediCare.Framework, Version=1.0.1.95, Culture=neutral, PublicKeyToken=1999fa3c42b9'.
I can see the class in the library which is in the references folder. How do I debug this issue?
My intention is to point the references folder to the library source code's bin directory (since the pdb file is lcoated there and any updates to the library will reflect in the application). However, when I point the references folder to the bin directory of the source code, I get the error message above.
Update The application was originally developed in VS 2008 and I am modifying it in 2010. I think I am confused about where the GAC assemblies would be, if I am using VS 2010 (2.0 framework location or 4.0 framework location) ? .NET 4.0 has a new GAC, why?
Update (06-26-2012)
The file in the GAC ("C:\Windows\assembly\") has been deleted. But this error is still occuring.
This could possibly be caused by version inconsistencies. Meaning, in order to fix this, I would do a complete clean build of your assemblies (and also an assemblies that might be nested inside an assembly). Just go out cold and do a new build on all assemblies. That should work.
Go into windows explorer, right click on the DLL file that your project is using that contains this class, and look at the version tab. Make sure version number matches what you see in the error message. My guess is that it won't.
If it does match, then check the GAC and make sure there isn't a different version of the DLL there that it could be picking up. To do that, go to windows explorer, and navigate to c:\windows\assembly. See if that assembly is in there with a different version number. If it is, you may need to delete it from the GAC (use caution though because other apps may depend on it being there).