I'm using Visual Studio 2010 for two applications, installing to IIS 7.5 on another server. Project A is a web forms web application, and Project B is an MVC 4 web application. During an attempt to set up StateServer between the two applications, I had added a reference to each's .dll in the other's References list. StateServer was abandoned in favor of using a cookie, and the project .dlls were deleted (I did not notice until the installation process that Project B's references were probably also in the list. VS seems to have deleted them from the References when the Project B.dll was deleted, since I did not delete those refs manually).
The problem is, the deployment package is still including them. (I'm just troubleshooting Project A, at the moment.) They are no longer listed in the project's References list, they do not appear in the folder contents under the obj/Release/Package folder, but they DO appear in the installed location after using Deploy -> Import Application in IIS! This includes Project B.dll, as well as many of it's references, such as DotNetOpenAuth.OAuth.dll.
I've run a search through my entire solution on Project A, and have no references to the Project B.dll. I've tried setting up a brand new site in IIS, and deploying to that. I've tried deploying under Staging (QA) and Release configurations, to make sure it wasn't just one of them that was messed up. Under Package/Publish Web, the settings you may be interested in are "Only files needed to run this application", and "Create deployment package as a zip file".
Running the site gives the error, "Could not load file or assembly 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies". This dll is not in the References list of the project, nor the deployment Package folder, nor the installed location's bin folder. It runs with no error, locally.
If I simply remove the extra .dlls manually out of the installed location, I get a compilation error when running the site, complaining a variable is not declared: var lotid = <%=defaultLotID %>; However, this variable is very much declared in the code behind: Public Shared defaultLotID As Integer = 0. And like I said, it runs fine locally. So it seems like a bogus error; just a canary in the mine, maybe.
Seriously, what am I missing? I had no idea how hosed I would be after making a reference to another type of web application. Thank you to whoever takes on the challenge of troubleshooting this one! I'm two days in and coworkers are baffled.
I ended up undoing all my changes, putting my code back to the TFS last check in version. I reintroduced the just the cookie code, built and deployed, I no longer saw the other project's dlls in the installation location. I guess it wasn't going to work to move forward through the reference and subsequent backout. Had to rollback to the prior TFS version, and start over.
Related
I inherited an Umbraco 7 VS solution where all Umbraco packages are conveniently added through nuget, along with a dump of the database.
I figured I'd have no trouble getting it to build, but I'm a bit stuck on the Umbraco.Web.PublishedContentModels. This file wasn't included in source control, and was added as a reference for the main web project and another supporting project. In the web.config the ModelsBuilder Modelsmode is set to <add key="Umbraco.ModelsBuilder.ModelsMode" value="Dll" /> .
Obviously if I could open the web project, I could generate the Umbraco.Web.PublishedContentModels assembly, but I can't because the project won't build because of the missing Umbraco.Web.PublishedContentModels assembly.
The model builder VS plugin is also just a frontend for the web interface, so that won't work.
This seems like a Catch-22 situation. Any idea how to proceed?
I have solved this using the following steps:
Downloaded a fresh Umbraco site, exact same version, from Umbraco
Edited the web.config to point to my existing database
Changed the ModelsMode for the ModelsBuilder in the Web.config (<add key="Umbraco.ModelsBuilder.ModelsMode" value="Dll" />)
Copied most of the bin folder of the original site to the new site
This allowed me to generate a Umbraco.Web.PublishedContentModels.dll. It wasn't quite the same, but with some minor changes I could get it to build
Once it builds, regenerate the original Umbraco.Web.PublishedContentModels.dll and undo the changes
In conclusion; don't lose that file.
Trying to lean Xamarin in vs2017
Doing the Quickstart
https://learn.microsoft.com/en-us/xamarin/xamarin-forms/xaml/xaml-basics/get-started-with-xaml?tabs=windows
After the project is created, you have to update the nugget packages, to fix the errors on "System"
This left me in a non compiling state. So I manually uninstalled and reinstalled the Xamarin.Forms and NetStandard Nuget package via the command line tool.
It then compiled and failed to deploy complaining about .netstandard. So I manually installed the .NetStandardLibrary nutget package.
It then compiled and deployed exactly once.
Now I'm getting a
Severity Code Description Project File Line Suppression State
Error MSB4064 The "References" parameter is not supported by the "XamlGTask" task. Verify the parameter exists on the task, and it is a settable public instance property. XQuickStart C:\Users\Brown.ericw.nuget\packages\xamarin.forms\3.6.0.264807\build\Xamarin.Forms.targets 90
Error.
How do I fix this?
Is Xamarin always this flakey? I mean this is a Hello world quick start, it shouldn't' be rocket science to get it working.
Seems you did a lot of things that might have corrupted your project.
Try to clean solution & delete Obj and Bin folder & restart visual studio.
If you still have the prob, you should check if you don't have a reference in your Standard Class Library that has nothing to do here (like a ref to your droid project or whatever).
VS somtimes have this kind of flakey issue. When you Make sure the code is ok, but VS is still promote some errors. You could refer to the following ways.
Clean your project, then re-build your project.
If you still get this error, close your VS, then open the project, delete all bin and obj folders in this project, Note:If you write a forms project, you should delete three times (drod,ios, PCL), open the prject, re-build your project in the end.
If above steps.it is not work, please delete the bin and obj folder in this project firstly, copy this project to another PC that installed VS, run this code.
The kpm pack command needs the runtime for the server - is it possible to install windows runtimes on osx just for the pack and deploy?
Ok, it seems that in order to recognise that the deployment is an aspnet vNext project and to handle that as a 'ProjectK Web Application deployment', you have to make it look like it all came from Visual Studio (or at least that was the only way I managed to get it to work right now)...
I did this by taking an example one from somewhere else...
I took a simple single vnext web project .sln file and changed the project name and project GUID.
I took the .kproj Visual Studio project file and did the same.
There isn't much that needs to be changed - only the name of the project and GUID. It's nice that there isn't any file lists in there so I feel that this might end up as a once-only activity...
I did find that there are some project structure rules that seemed to make it break. You seem to have to have the sln file in the top level folder and a folder underneath for the web project. If there is ONLY a web project then this might seem overkill, but I tried collapsing everything up to the top with the sln file correctly pointing, but that didn't work.
The other thing that you need to make sure you have is a reference to "Microsoft.AspNet.Server.IIS" in the project.json dependencies. Without this, the AspNet.Loader.dll and bin folder don't get deployed.
Apart from that, I am now able to use Sublime Text (or whatever I want on osx), test using "k kestrel", checkin through git and it gets deployed automatically to an azure web site! yippee!
Actually this makes much more sense because it is letting the target decide upon the binaries it needs to satisfy the deployments. Next challenge might be to get it to pull 'my' libraries from a custom NuGet source to get my binary libraries in there and avoid uploading ALL of the source to the website!
Oh - and another tip: Quit kestrel with 'Enter' for a clean quit instead of Z which leaves the port listening but non-functional!
I have a MVC 4 web project that I have been working on for about a year. It is currently published and running on azure in production, and has been working there for about a year. My dev machine malfunctioned and I had to replace it. After setting up my dev environment and retrieving my codebase from my repository, I made a very minor change to one of my pages (I corrected a typo, changing "teh" to "the" in the text of one of my .cshtml pages. I downloaded and imported my azure publish profile settings from:
https://windows.azure.com/download/publishprofile.aspx?wa=wsignin1.0
which seemed to correctly populate my publish dialog and I attempted to publish my correction to staging. However, when it builds prior to publish, the output window starts to show a series of "the type or namespace {x} cannot be resolved" errors. It accumulates 72 such errors for various referenced assemblies, and then it exits with "build failed".
A few seconds later all those errors disappear and if I rebuild the solution, it does not give me those errors, which ONLY appear on a pre-publish build. I can run the project in testing environment and it works fine there.
I have tried everything I can think of. Has anyone ran into this before?
After a week of frustration, I finally figured out what was happening. I had a email library, rebex, that I had purchased that the project used. It was installed on my original development machine, where the application was publishing correctly. The .dll file for the rebex library was incorporated into my source code so that when my new dev machine was configured and the source code restored, the .dll file was present, and worked in development mode.
However, it would not publish to production until the installation file was re-downloaded and the rebex assemblies were registered to VS2012 and the GAC.
If anyone else has this issue, check to see if you have purchased or licensed libraries that need to be properly registered.
MSD
I hope someone else has encountered this because its driving me batty.
I recently got a new laptop so I've been setting up my Visual Studio solutions (VS2010 with .NET 4.0) that I saved off my old machine. One of them is a simple console app that I use to simulate some things for testing. It references 2 assemblies that I have in another solution that I am working on now. This used to all work fine as expected but ever since moving to the new machine I get the dreaded "The type or namespace name 'YourAssembly' could not be found (are you missing a using directive or an assembly reference?" error message. The references are clearly shown in the Visual Studio but when the project builds it does not copy them to the bin directory which explains the message. Initially I was just referencing the dlls the way I would any 3rd party dll but I even tried removing that and including the project files in my solution and referencing them that way and still it fails. I've verified that the dlls have their 'Copy Local' property set to true and they do. Its really bizarre because the project references several other dlls that are just 3rd party assemblies (for example NLog, GData, etc) and those all copy over fine but not these two for some strange reason.
Here's one more piece of oddness. If I add some code to the console app that references my assemblies it says it can't find it. If I then re-add the assemblies to the references, the error disappears until I try to build it again and then it returns. Is this a VS bug or what? I've never seen this kind of odd behavior before.
thanks
One case that I have seen that caused the problems you are talking about:
Including references to dlls that are built in-house, linked to a specific version of the dll. Get a new copy of the dll (with a different version number) and the build breaks.
The solution in this case is to set the DLL reference property Specific Version to false. The version of the dll is ignored (in my case, it is safe to ignore it), and the build works properly.
I've also had weird errors like this where the NTFS permissions were set on the old file with an old login, but the new machine didn't like the old permissions.
Also, sometimes the old .sln or .csproj file refers to an odd file path that you can't seem to edit from within VStudio. Try opening those files with notepad and make sure the paths aren't broken. You can usually edit and save with fixed paths and things will work again.
Hans had the answer above but I was unable to find that post through searches so hopefully if you stumble upon this question I can save you several hours of frustration.
For some bizarre reason the 'Target Framework' was defaulting to ".NET Framework 4 - Client Profile" in the project properties. I double checked and it seems to do that whenever I create a new console app. It must be version related thing in VS because I hadn't encountered this issue previously in 2010.
To fix:
Right click on your project, choose properties
Under the main Application tab, set the Target Framework to be your framework of choice but NOT one of the 'Client Profile' options
Save and build as normal