Using the latest stable of CC.NET (new to it) and VS 2010.
I have defined project files for simple C# projects (4 in total) and one MVC Project.
The C# projects all compile correctly; however, the MVC3 project refuses to build.
I receive the following error in CC.NET:
error MSB4019: The imported project
"C:\Program
Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
was not found. Confirm that the path
in the declaration is
correct, and that the file exists on
disk.
After searching around and finding This link
and This other link (both referring to older versions of Visual Studio), it seemed that the general solution was to copy these files from that directory to the solution directory, add them to the solution with visual studio, and then change this line in the .csproj file:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
To this:
<Import Project="$(SolutionDir)\Microsoft.WebApplication.targets" />
However, this technique that worked for other VS Versions produces a different result in VS 2010: I receive the .NET Project upgrade wizard, as if upgrading the project from an old version of .NET. This strangeness is compounded by the fact that even if I do an undo and re-save the file exactly as it was, I receive the same message. It's as if the project has been marked dirty or something else has changed somehow.
Anyone have any ideas? This seems like it should be easier, but I can't seem to find another resource on it anywhere. Hoping StackOverflow will come through per usual. :)
Thanks in advance for any help!
The .targets file for v10.0 also has an assembly in the install folder - Microsoft.WebApplication.Build.Tasks.dll. Did you copy that file over as well? That will likely be necessary for the .targets file to work correctly, though that may not be the cause of your problem.
It sounds like CC.Net isn't getting a proper reference to the msbuild executables.
Trying installing both of these on your build server (that's who I was able to get past that exact error).
Links :
Windows SDK .Net 4
VS2010 Integrated Shell
Related
I have a project which works fine. This morning, I created a new TFS project and published all the code from Visual Studio 2015.
On another computer, also via VS2015, I've logged into Visual Studio Team Services to grab the same project and downloaded all the code
When I try to build, there are over 100 errors, but the cause appears to be the same. It can't find resources, and the error messages all appear to be
The type of namespace name 'some name' does not exist in '....' (are you missing an assembly reference?)
So, I expand the References and I'm missing pretty much all of them. In fact, other than the references within my own project, the rest are not there
Looking at the properties shows no path. Back on the original PC I see the path to any of the .dlls is similar too
C:\Users\Me\Documents\Visual Studio 2015\Projects\MyProj\ToT\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll
Is the issue that since this path doesn't match on the 'faulty' machine it can't show... Therefore what is the solution to this
I checked and noted that the files do appear to exist when I look at them in File Explorer.
All system references missing Visual Studio 2013 NuGet Async did not help
Please note, this happens with all projects in my solution, but not consitently. For example, EntityFramework is missing from all, but System is missing from my UI layer, but not from my BLL layer
Is there a way to fix this?
You need to run the update-package -reinstall command to reinstall all referenced packages.
I had the same problem, there are lots of answers by now but I will still post it here:
1.Close Visual Studio
2.Manually delete the local “packages” folder
3.Reopen the solution, and rebuild. (Nuget should restore the packages)
Source:
http://robertgreiner.com/2013/09/team-foundation-service-build-error-nuget/
Go to TOOLS -> nuget package manager -> package manager console -> and run to the console : UPDATE-PACKAGE -REINSTALL .
Clean your solution, rebuild and you are ready!
Sounds trivial but your missing references to system.xxxx could imply a problem with the .NET Framework, what version are you using and is it installed properly on your 'faulty' machine. Might be worth a re-install/repair? I'd check what versions are actually referenced too.
As for NuGet, make sure that Enable package restore is set as:
Also, I had a problem similar to this once and I had to upgrade the NuGet package manager to version 3 in Tools -> Extensions and Updates (You need to uninstall and then re-install as update won't work)
Finally if that doesn't work, check in File Explorer in the packages path and delete all packages. They should not be included in source control as this is what NuGet will download. If they are there or partially there, sometimes it will not download them.
Verify the .NET version:
Open the project properties pane and check the Target Framework:
Ensure this version of .NET is installed. OR change the target framework to a suitable version
First, go to VS--Tools--Extensions and Updates to check whether there are updates, install all updates. Then select one reference with a warning icon, check the Specific Version property, if the value is True, change it to False.
If the issue persists, check the Reference Assemblies of .Net framwork on your two computers, to see whether they are under the same location (the .Net framework is supposed to be under *C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework*).
=========================================================================
11/5: To avoid references missing, you can either check in all references to source control and reference from the source controlled ones, or use Nuget Package Manager to install packages. The previous is not recommended now, try Nuget Package Manager.
Before hitting your head against the wall with the million of Nuget 'fixes' you need to make sure you are getting ALL the DLLs that are in your Bin folder under source control. For some reason a simple "Get Latest Version" is not enough. Visual Studio will keep telling you all files are up to date but apparently this doesn't mean all the files under source control are downloaded (or it does and what happened to me is just a sassy bug). Anyways, to make sure you are truly "getting all" you need to force an update by using the "Get Specific Version" command with the "Overwrite all" option checked as VS suggests. To do this:
Go to your Bin folder in Source Control Explorer (Or w.e folder you truly want to get all)
Right Click > Advanced > Get Specific Version
Check the "Overwrite all files even if the local version matches the specified version" checkbox
Click Get
By doing this I ensured all the referenced DLLs were downloaded from TFS and for me that solved the problem. I'm using Visual Studio Enterprise 2015.
In one of our projects, I've recently converted from the (now broken) old-school MSBuild based automatic package restore to the shiny new automatic package restore in Nuget 3.0 (Visual Studio 2015 RTM default).
As the official guidance suggests, I have created a .nuget/Nuget.config file in the solution folder to stop it from uploading the binaries. No more clutter in source control. Life is good.
However, this doesn't work on other machines if the Nuget.config isn't itself included in source control, so I have done just that. Now life is bad again.
Visual Studio can't load Nuget correctly and the error log indicates that it can't open .nuget/Nuget.config read-write. Which is fair enough, since it's under TFS source control and not checked out.
So here's the question: How to have my cake and eat it, too?
Upgrade to Nuget 3.1.1, it behaves as expected and doesn't open the file read-write.
Delicious cake.
The discussion for this (closed) issue is here: https://github.com/NuGet/Home/issues/1103.
I am working through setting up our first build definition through TFS 2013. I have worked through all of the errors (mostly missing reference files) except one:
Type 'iDB2Command' is not defined.
The type is part of IBM.Data.DB2.iSeries.dll, which I have placed on the build server in the appropriate location. I am really at a loss as to what to do in this situation.
Obviously building through Visual Studio works just fine. The file is not registerable. The iSeries client/SDK installs are not necessary (I do not have them on my machine, and I can build).
My best guess is that it wants the .NET 2.0 SDK (TFS is running on Windows Server 2013 and I already had to install several versions of the Windows and .NET SDKs).
How do I get my build to see this file and complete?
Ultimately this appears to have been a permissions issue. By following advice similar to the answer to this question (which I had to do for the Excel reference), I needed to put the IBM DLL into a Libs folder within the Team Project.
Once I did this, and updated the references in the solution, the build worked just fine.
I'm working on a project in Visual studios 2013. I was trying to figure out how to do something and was recommended to look at another project on TFS that does something similar. When I got latest version of this other project, I found out it was made in VS2010. It migrated it to VS2013, and locked the file to me. I undid the changes because I don't want to modify this other program. I was unable to find a way to open that file without it trying to lock the file to me with migrating to VS2013.
As an attempted solution, I copied the file elsewhere on my computer and tried opening it without connecting to TFS. I assumed this would allow it to migrate to 2013 without updating the database. It still had issues and gave me this error: Solution file '%s' cannot be migrated because the solution cannot be checked out from source code control. To migrate the solution, make sure the solution file can be checked out and re-open it.
How can I open this solution without updating the TFS solution and locking the file to myself?
I just ran into this same problem. I checked the permissions on the solution files I was trying to open and saw that it was set to 'read-only'. I deselected read-only and the solution opened.
If everyone else is using VS2010 with Service Pack 1, then upgrading the solution isn't a problem. People will still be able to open it in VS2010 SP1, even if you check it in. See the Visual Studio 2013 Compatibility notes on MSDN for specific things to watch for.
Alternatively, after checking the files out but before opening the .sln file, create a copy of it in the same folder calling it MyProject2013.sln (for example). Add this new solution to source control using Source Control Explorer and then open it, letting Visual Studio upgrade the .sln file as it would normally. The 2010 .sln file will be left untouched and you should be OK to do what you like with the 2013 solution.
Upgraded from MVC Beta to MVC RC1.
Re-pointed all references in the project to point to the new assemblies
Rebooted
Everything compiles (and runs!)
But...
Opening a view (.aspx) in VS and she just disappears!
Event Viewer gives:
NET Runtime version 2.0.50727.3053 - Fatal Execution Engine Error (6E075E00) (80131506)
Update 1:
Not ALL .aspx pages!
Also - it seems that writing the question on StackOverflow is the fix! grr
Update 2:
Not had the problem since posting the question but:
The only plugins I have are VisualSVN and Resharper.
I do seem to have something in the GAC for System.Web.Mvc - but it looks like the wrong version and I can't get rid of it.
I believe it must be related to some intelli-sense colouring or similar during the render of the code of the .aspx page - but now it's stopped it is hard to confirm...
Try removing all bin/obj directories, and clearing your Temporary ASP.NET Files and %TEMP% directories. Then issue the following commands from a VS2008 command prompt:
ngen /delete System.Web.Mvc
ngen /delete System.Web.Abstractions
ngen update
Also ensure that all your references (MvcContrib, anything else built against MVC) are pointing to the same version of MVC as all the others.
This seems to have worked for me (so far)
There are some framework bugs that affect all VS add-ins etc if they reference System.Core v3.5. Start by clearing out the NGen cache. "ngen update", "ngen /delete [assemblyname]" or a sweeping "ngen /delete *" usually does the trick
More details + workarounds for this (and/or similar) issues here:
http://forum.huagati.com/topic5-addin-causes-ide-to-close.aspx
http://code.msdn.microsoft.com/PowerCommands/WorkItem/View.aspx?WorkItemId=8
http://www.jetbrains.net/devnet/thread/274657
Update: finally someone from MSFT acknowledge that there is a problem:
http://blogs.msdn.com/jnak/archive/2009/02/15/potential-crash-in-vs-when-using-the-mvc-rc-on-windows-azure.aspx
Update 2: An attempt at a workaround (VS2008 add-in): http://www.huagati.com/ProjectLoader/
Update 3: Microsoft has a CLR patch (KB963676) that fixes this problem. It is not available for download from microsoft.com but it can be requested through MSFT support / PSS.
Update 4: The CLR patch is now available for download from Microsoft Connect:
https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=16827&wa=wsignin1.0
http://blogs.msdn.com/jnak/archive/2009/02/26/fix-available-asp-net-mvc-rc-crash-in-a-windows-azure-cloud-service-project.aspx
I had to remove the PowerCommands add-in to get VS working again.
I've had problems like that before. It was the webform editor. If you right-click the aspx file and choose "open with..." and select Html-editor the ide will most likely not crash on you.
Try disabling addIns one by one.
For me it was a conflict between gallio and testdriven.net I think.
Microsoft have now released a hotfix to resolve this issue.
See https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=16827&wa=wsignin1.0
Phil Haack elaborates further here - http://haacked.com/archive/2009/03/06/hotfix-for-installing-aspnetmvc.aspx
I'm having the same problem and have posted a reply on the official ASP.NET MVC forum at http://forums.asp.net/t/1378448.aspx
I'm not sure, but are you also seeing reference to the Html helpers not showing up in the views (when they don't crash)?
I don't have Gallio installed, but I do have Resharper. I'll see if disabling that helps (although that would cause me a lot of anguish).
Update: Resharper wasn't the issue, but rather the plugin "Huagati DBML/EDMX Tools." It seems some plugins might be conflicting and I encourage people to disable all plugins as a preliminary step in debugging the crashes.
I have found that any compile issues with the master page or the page itself -- even warnings -- can cause this to happen. So close the project, delete the bin and obj directories, then re-open the project. Next open your master page(s) and any other recently changed aspx/ascx files. It is important to open all before you compile.
Now, viewing each page one at a time, compile the project and resolve the warnings. Once all the warnings are resolved, close the pages and try to re-open them.
I got the exact same error. At first I thought it was the Spark View Engine add-in (because it crashed opening views) but after Christian's comment about Gallio and TestDriven.NET (I have both) I uninstalled Gallio and now it works.
The problem was indeed, powercommands for VS 2008. Uninstall them if you can live without them and the aspx pages/designers will open fine.
Actually I think my problem was some rogue copies of the Beta MVC DLLs hanging around.
I deleted them all, uninstalled the RC1 and made sure they all left the GAC and then reinstalled the RC1. So far everything seems fine.
This occurred for me after setting the reference to System.Web.Mvc to Copy Local = True. This placed the System.Web.Mvc.dll file in my bin folder.
The next time I opened any aspx pages Visual Studio crashed. Changing the dll in the bin to System.Web.Mvc.dll.bak fixed the problem.
I finally (after a fews days of trying everything) got it resolved by uninstalling the Spark View Engine add-in, which crashed when opening .aspx and .js files!