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.
Related
I have a .NET Core console app and a .NET Standard library. The app consumes the library via a nuget source in RELEASE, and a project reference in DEBUG, via a Condition on each ItemGroup.
This is working great locally, as I can make changes and test both the library and the app in parallel. When the sources get committed (obviously the library before the app), the library gets published, and the app consumes the published package.
Now, this app is also one piece of a docker-compose, and I want to be able to debug while running in Docker. This is perfectly supported with Visual Studio, but it also means my app is built against the library package available in my nuget source, not a locally-compiled and debuggable one.
I do have clues as to how to work around this, but would like to know if I'm just not either missing something, or trying to reinvent the wheel (though I really like new wheels).
I could copy the library's sources and project as part of the Dockerfile, and make sure it respects the Condition within my app's csproj. This sounds patchy.
I could have a local folder within the app sources where I copy the freshly built library's .nupkg, which would be copied via Dockerfile before dotnet restore, and also mentioned in the Nuget.Config, but ignored in .gitignore.
I'm about to try #2. Is there a simpler approach?
Thanks.
I have a MVC 2 project created in Visual Studio 2010 that use MvcSiteMapProvider.dll and works fine. But when loading the project in Visual Studio 2013, everything else work fine except it crashes at
Html.MvcSiteMap().SiteMapPath
The error message is
An exception of type 'MvcSiteMapProvider.MvcSiteMapException' occurred in MvcSiteMapProvider.dll but was not handled in user code
I believe that MvcSiteMapProvider.dll cannot be loaded correctly. I need help on this. Thanks.
Note that there is a separate DLL for each .NET framework version, and I suspect you are targeting the wrong framework. This can happen if you install MvcSiteMapProvider into your project and then change it to a different .NET framework version.
NuGet does not automatically upgrade/downgrade packages to the currently set framework version. This step must be done manually. The best way is to completely uninstall and reinstall the package as per this document. Also be sure to read this before attempting it.
But do note that if you do this NuGet will not remove any files you have changed (like Mvc.sitemap) and then prompt you whether to overwrite them. You should normally say no to each prompt to ensure your custom configuration is not overwritten.
Also note that it is not sufficient to use Assembly Binding Redirection with MvcSiteMapProvider because with each .NET framework version we create a separate build (DLL) that takes advantage of features that are not present in prior versions.
I'm thoroughly confused about how to properly deploy ASP.NET MVC with my application. As far as I understand, there are the following ways you can get it on a machine:
You can download a separate installer and install it on a machine that has the approprite .NET framework (although which MVC version requires which .NET framework?)
Some versions come along with .NET framework itself (though I can't find which version of MVC is shipped with which version of .NET);
Some versions are installed with Visual Studio (though again, no idea which versions are installed with which versions of VS). In this case, you can set Copy Locally to true for these references and perform a "bin deploy". You might need to add some extra references though (not sure which though).
You can also download MVC as a NuGet package, in which case it also downloads some other unrelated packages like WebPages, Infrastructure and Razor (which is my personal WTF - wasn't Razor a core part of MVC?). In this case the build process will automatically do a "bin deploy" by default (I think...)
So... WTF? What is the proper way to add MVC to your development workstation, what is the proper way to add the references to your project (NuGet? GAC?), and what is the proper way to deploy it to the target server (separate installer? .NET installer? bin deploy?)
"Proper" Development:
The "proper way" (by which I mean standard/redistributable way) would be using Nuget for your references. This means you can easily manage different versions and anybody else working on your project has a standard repository from which to pull the external requirements.
The NuGet documentation has a decent explanation of how to add references.
To install the appropriate version of MVC for developing through Visual Studio, just download and install it from the ASP.NET MVC website. This will install the necessary templates for you to create a new MVC project in Visual Studio. This will also include the necessary binaries, etc.
"Proper" Deployment:
Use bin deploy to deploy to your webserver. This means you don't need full admin priviledges to install the MVC requirements.
Phil Haack's guide will walk you through the process of bin deploying MVC3+
Keep in mind, the web server does need the appropriate .NET platform installed. You should install this via the appropriate redistributable installer if it is not already installed on the server.
Referring to the deployment i publish my asp.net app (i usually make web applications) to the file system in a directory (you can set also a server there, but i don't like it) and make an upload to the server with an FTP client of all the deployed folders. All the changes that i make to the app after (like bug correction) i deploy all the app again and upload single parts.
I hope i get your question in part, this is my first answer in SO.
We are in the middle of development for a core ASP.NET MVC web project and a customer plugin in the form of an MvcContrib plugin web project -- a web project injected into the core web as an area. The plugin is a soft reference in the core project, so it can be developed completely separately and dropped in.
I am trying to generate a way to debug/code the plugin, so that the multiple custom plugins can be developed independent of the core web.
The developers should only have to worry about coding and testing the plugin code. Also, I don't want them to change the core code in this custom plugin project -- that should be done in the core anyway.
I created the core web as a NuGet package and included all the necessary files so I could include it in a web.
My thinking was that I could create an empty web, install my core web, and the developers could have an F5-driven debugging environment.
I tested by creating a blank Mvc project, installed my core package and included one of my plugins. I changed the namespace of this empty web app to the namespace of the core web, thinking that Visual Studio debugging would properly attach and my core assembly.
Simple VS debugging in the empty app does not work -- I receive an HTTP Exception, most likely due to my routes not being registered. I also see that my log4net is not creating its logs folder, so I know the assembly's app start is not being called.
So I see that VS is not attaching to and calling my core assembly.
Can I use this empty web as a host project for my nuget installed web and debug? If so, what configuration am I missing?
If not, how can I include the core web in each customer plugin project in such a way that I can drop my DLL into the bin and debug it?
Using:
Visual Studio 2010
ASP.NET MVC2
The way we are doing things that works pretty well is to use a combination of Web Activator and Razor Generator (available as a Visual Studio extension). In order to access the views within the core web application, the consuming client application needs to know about them, either because they are all included as file references inside the Nuget package (messy) or because they are compiled into the core web dll. You can do that using Razor Generator. Once installed via Nuget you would need to change the Custom Tool property for each .cshtml file to RazorGenerator, which will create a .generated.cs file for each view. This will allow your sample client to use the layout and views from the core web application.
David Ebbo has some useful blog posts on Razor Generator
Couple that with Web Activator to create a PostActivationStartMethod that runs your initialisation code (such as initialising Log4Net) and you should be good to go. We've had this running in 2 scenarios - consuming the framework package via Nuget and adding a project reference directly. Debugging was not working for the Nuget package consuming route but we don't include the pdb files in the Nuget package. We can debug when adding a project reference directly though.
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.