Have taken over the management of a system written in C# MVC. It's a pretty big project so working my way through it bit by bit to learn what everything does. I've just made my first set of changes to it, and am ready to deploy. To do this I changed the debug mode to production which has have all the correct settings for deployment on the server.
However, when I try to compile the project I get lots of Errors and warnings. Most are to do with the third party NLog library which is used in the project.
The type or namespace name 'NLog'
could not be found (are you missing a
using directive or an assembly
reference?)
I have double checked the using statements which are all okay, and in References there is a reference to NLog. In my handover guide for this project, it states that the NLog.dll should be within the bin folder in the project. Now, if I go into the folder structure of the project, I can see this bin folder which does contain NLog, and other objects that are throwing me errors. However, I cannot see this bin folder at all in the folder structure in Visual Studio, so I'm wondering is this my problem?
If anyone could offer any advice I'd be so grateful.
Thanks.
You shouldn't see the bin folder in the solution explorer, so that's not the problem. My suspicion is that NLog is included in a class library project that is required by some other project in the solution. For some reason, this class library project is not compiling and thus you have this library as well as NLog (which it brings along when it's compiled) not available. I'd make sure that you have NLog included as a reference directly in all projects which directly reference it or have a dependency that references it. Pay particular attention to any test projects, which won't typically get built when you build your production code using the right-click menu build action, but will when you build the entire solution.
Related
If I try to open one of my projects in VS2010 on our build machine I get the error: "The project type is not supported by this installation". This is because I don't have MVC 4 installed on this machine. As I would like to keep my build machine as clean as possible I would like NOT to install MVC 4 (and deploy/reference the needed DLLs manually). Is it safe to edit my project file and to remove {E3E379DF-F4C6-4180-9B81-6769533ABE47} (MVC4) from <ProjectTypeGuids>?
You would be editing you solution file, not the project file in this case.
Well, if it's only you working on this, or you don't check the .sln back into source code once you have removed it, then yes.
If you do, it will be missing for others, who have MVC installed.
Alternatively, leave it in there as unloaded.
Another workaround would be to create a separate SLN file with everything but the offending project in.
EDIT
You would need MVC installed to be able to open / edit / do anything with this project.
I'm trying to publish a solution that contains several projects -one of them is MVC- to IIS7.
When the MVC project is published and some views are being accessed I get the following error:
Could not load file or assembly 'NHibernate.Mapping.Attributes, Version=3.2.0.0, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The system cannot find the file specified.
This happens because the view I'm trying to access is calling a function in another project in that solution and needs this library!
but this library is not contained in the MVC project!
I was able to solve it by referencing that DLL in the MVC project! but I need another solution, because it doesn't make sense to reference every single DLL in all the other projects!
I'm using the "Web Deploy" publish option for the MVC project, is there another way that I can publish it and make it work without referencing all the DLLs from all the other projects?
There is an article on how to deploy assemblies that are not referenced by your MVC project directly:
http://haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx
Basically you need to create a folder in your project called _bin_deployableAssemblies and add your assemblies to it. They will get deployed with the website.
Here is a quote from the article:
So here’s the kicker. If you’re building a web application, and you
need an assembly deployed but don’t want it referenced and don’t want
it checked into the bin directory, you can simply add this folder
yourself and put your own assemblies in here.
I've been working on a web application (ASP.NET 4.5 Web Forms), and then added it to TFS to make the source code accessible to the client. I had no trouble getting it added to TFS, but when I got latest on a different machine (than the one I developed on) to test if TFS was working, I'm running into a bunch of reference errors to basic things like EntityFramework, Microsoft.ScriptManager, System.Web.Optimization. A client has run into the same issue when he checked out.
The thing is, if I create a new web application project on this machine, it has all those same references, but they're working correctly.
I've seen suggestions to add the actual DLLs to the project in a /lib folder, then reference them instead, but I don't think that's the right course of action for these basic, built-in assemblies.
One more thing- when I publish to Azure, it works just fine.
Any clue how I can get these references working properly?
Full list of broken references:
- AspNet.ScriptManager.jQuery
- AspNet.ScriptManager.jQuery.IO.Combined
- EntityFramework
- Microsoft.AspNet.Membership.OpenAuth
- Microsoft.Aspnet.Web.Optimization.WebForms
- Microsofot.ScriptManager.MSAjax
- Microsoft.ScriptManager.WebForms
- System.Web.Optimization
EDIT: I finally got this figured out. Apparently even these key assemblies are generated into the "packages" folder where the project is located. I added this folder to source control and it worked fine.
Right click on one of the references (on your machine) select properties, then check the full path to where the assemblies are located.
If they are in a folder called packages under your solution then they are NuGet packages not built in assemblies. Which means you either need to check the packages folder into source control, or right click the solution and enable package restore mode.
If they are program files then they aren't really built in assemblies either, they're likely installed by something else you installed onto that machine.
I have a solution with 2 projects:
Project 1: Wrapper.Dll which contains a NLog wrapper. NLog and NLog.Extended have been installed with Nuget.
Project 2: is an ASP.Net MVC project which contains a reference to project 1.
When I try to run the web project, it throws an exception because NLog tries to load a target renderer from NLog.Extended.Dll.
If I check the bin directory of Wrapper.dll, I have NLog.Dll and NLog.Extended.Dll.
If I check the bin directory of the Web project, I only have NLog.dll.
How can I tell Visual Studio to copy the NLog.Extended.Dll from project 1 to project 2?
EDIT: Adding some dead code that use something from NLog.Extended.Dll makes the file copied.
Is there any cleaner solution?
Thanks
Unfortunately no, there is no cleaner solution. If no objects from the NLog.Extended assembly are referenced (directly or indirectly) from your code, it will not copy it. This is of course a problem since the layouts are just strings and not a direct reference. You could use a post-build event, but that's an uglier solution in my opinion.
You could add a reference to NLog.Extended.dll in the web project if it depends on it.
I am building my deployment process and I am running into a really annoying problem.
Using Visual Studio 2010 Sp1 on a .Net4 project with ASP.NET MVC3 that I want to deploy to an IIS7.5 webserver. The deployment works fine - both from Visual Studio and command line - except for this one important part:
I am using NHibernate (with Fluent NH) in a class library that is referenced by my web app. These were installed using NuGet, and also show up on the server when deployed.
However, these depend on some other libraries:
Castle.Core
Iesi.Collections
NHibernate.ByteCode.Castle
These are also fetched by NuGet, they are referenced in my class library, and the references have "Copy Local" set to True. However, out of these three, only Iesi.Collections actually show up on the server!
Of course, I can copy them manually, but the next time I run the deploy, it will delete them. Deleting unused files is actually something I want, but these files should not be in that category!
What can I do to make Web Deploy respect the fact that these guys are desired members of my application!?
Try adding those assemblies as references to your web project otherwise implicit references in class libraries might not be included.