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
Related
I have cloned code from our company ADO area (someone else's code files) and when loading it in visual studio 2022 I cannot load one of the projects in the solution (unloaded). I get the following two errors:
Error 1: The Web Application Project is configured to use IIS. Could not find the server on the local machine. Make sure the local IIS server has been configured to support secure communications.
Error 2: A project with that name is already opened in the solution.
My colleague who originally wrote the code can clone the code and doesn't get the same issue.
I am also getting a lot of dbl files and debug files automatically populating in the changes and every time I make a change to the code it generates more changes for these kinds of files which is quite hard to then see in git changes what changes are mine and what have been autogenerated.
Can anyone help?! I am new to the Development world, and this is really stumping me!
I have tried going into the user file and setting use IISExpress to false. Was expecting that to resolve the error 1 message but it hasn't.
I have tried putting a gitignore file into my project but it isn't ignoring the files in the changes being auto generated in git changes.
I've been using this same Sitecore project, for more than 2 years now. Upgraded to Sitecore 7.0 this spring, and everything just ran like it should.
But yesterday, suddenly out of nowhere, i can't seem to run my project anymore. I'm using Visual Studio 2013 with IIS Express (64 bit). And when i try to build and run my site through localhost, it just hangs. I even tried to let it load for 1 hour+, but it still just loads with nothing happening.
I tried to debug it further with Fiddler, but nothing happens. I even tried to delete a bunch of important files, like web.config. But it still just loads forever, with no error.
If i create a new empty web project, i can start it through localhost instantly. So there must be something weird happening with my Sitecore project.
Does anyone have any suggestions for debugging this or have you ever experienced anything like it?
I've nearly tried anything.
I am not sure what version you upgraded from, but I would do the following (in order) to troubleshoot the issue:
Depending on what version you are upgrading from, you may have been running your app pool on .NET Framework v2.0 instead of v4.0, which is required for Sitecore 7. Open up IIS, go to your app pool for the site and make sure that it is correctly set to run on .NET v4.0 and not v2.0. If it was set to v2.0, change it to v4.0 and try access the site. If the issue persists or if the app pool was already running on v4.0 continue to the next step.
As implied in step 1, Sitecore 7 runs on .NET 4.5. If you are upgrading from an earlier version of Sitecore, it is possible that your site is compiled using an earlier version of .NET. Right click on your project files in Visual Studio, click on Properties->Application and make sure that the Target Framework for each of the projects is set to .NET Framework 4.5. If they were set to a different framework, change them, build your solution again, and then try to access your site. If they were already set to target .NET 4.5 or if the issue persists continue to the next step.
Double check the permissions on your site root. Make sure that NETWORK SERVICE and/or your IIS User has all of the necessary read and write permissions for the directory. If they do not, apply the permissions and try the site again. If the problem persists, continue to the next step.
Delete all of the Sitecore DLLs and the DLLs generated by your projects. Copy fresh DLLs from a clean download of Sitecore 7 back into your bin/reference directory and build your solution again. Try to access the site again. If the issue persists, then the problem is likely in temporary internet files or in a config. Continue to the next step if this is the case.
Delete your Temporary ASP.NET Files from the Framework and Framework64 folders found in the C:\Windows\Microsoft.NET directory. Note that you must go into the directory for the version of .NET that your app pool is running against and delete the contents of the Temporary ASP.NET Files directories. It may be necessary to stop your app pool when you do this. Try to access your site again and if the issue persists, move onto the next step.
Try replacing your web.config with the default from a clean download of Sitecore 7, but be sure to back yours up before-hand so that you do not lose customizations, as you will want to add them back in after. Try your site again. This time, you may get an error if something in your code is dependent on the web.config. It is a good thing if this happens, as it means that your site is now working and you have only to add back in your customizations to resolve the errors. If your issue persists, continue to step 7.
If your site is still hanging, try replacing all of your configs in the App_Config directory, one at a time, with their clean copies (excluding ConnectionStrings.config and DataFolder.config, if you are using them). Additionally, disable/backup and remove all custom configs or configs for modules that you have installed that are not Core to Sitecore. Try to access your site again. If necessary, resolve any config errors by merging your changes/re-enabling your configs one at a time until you find one causing the issue or until all errors are resolved.
If your issue continues, post your the Sitecore version you upgraded to, the version you upgraded from, and any modules you have installed as a comment on this post.
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.
I am creating my own site template for SharePoint. Everything has been going fine, building fine, deploying fine. For unrelated reasons, I needed to reboot my development server. I then made an update to my custom.xsl file and attempted to deploy in Visual Studio 2012. Even though it says Deployed Successfully, My changes are not reflected in SharePoint, and I received the error in my question. Additionally, I am getting 32 warnings that this or that attribute is not declared, even though I made one small change (added a link for testing) to the blog.xsl I copied my custom .xsl from. I reverted all changes, attempted to deploy again, but cannot get past this error now.
Any ideas where to start looking to solve this? Needless to say _layouts is NOT in the root of the C drive, but it the 14 hive under Templates.
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