I downloaded the TFSBranchTool VS Extension Project.
Rebuilt and Installed, but when I try to apply Initial Structure I get the following Error:
Exection Error:
Exection of Action 'ConnectSourceControl' Failed. Details: Could not load file or assembly Microsoft.AlLMRangers.BranchTool.SourceControlWrapper......
Any idea what might be causing the problem ? I tried on 2 different Servers! , I got the latest Update of VS2012.
I got VS2012 SDK installed and Vs2012 ObjectModel too, not sure what I'm missing!
We have posted an update to the sample code on http://vsarguidance.codeplex.com/releases/view/96222, which addresses this bug.
The issue was that Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll was missed in VSIX package. As action execution engine using MEF to load actions, it has no direct references to actions implementation assembly.
Vladimir from the team fixed the issue by specifying assembly as the MEF asset in the VS extension’s manifest file. Now it’s redistributed inside the extension package.
Can you verify that you have the file Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll
in the following folder:
%LOCALAPPDATA%\Microsoft\VisualStudio\11.0\Extensions\Microsoft. ALM Rangers\TfsBranchToolVSExtension\1.0
If its not there - try deleting the TfsBranchToolVSExtension and re-install the VSIX.
Related
The Restore step fails in my build definition with this error:
error NU1100: Unable to resolve 'AutoMapper (>= 6.2.2)' for '.NETCoreApp,Version=v2.0'.
This is in a .NETCoreApp 2.0 that is using AutoMapper. Restore succeeds locally in VS 2017. Locally I am using dotnet sdk 2.0.0, and nuget 4.3.1. On the VSTS (cloud) server, I am specifying the latest nuget version, 4.5.0. I have tried many other versions, including 4.3.1 with no success.
I know there is an older, similar question here, but that was never answered satisfactorily, in my opinion.
If I look at the meta data in VS, at the top of one of the Automapper files I can see this:
Assembly AutoMapper, Version=6.2.2.0, Culture=neutral, PublicKeyToken=be96cd2c38ef1005
// C:\Users\randyg.nuget\packages\automapper\6.2.2\lib\netstandard1.3\AutoMapper.dll
From this you can see it's taking the netstandard1.3 version, which is correct. I'm wondering if the nuget on the build server is looking for a netcoreApp2.0 folder, rather than the netstandard1.3 folder? Following this theory, I tried adding this to my .csproj file:
<AssetTargetFallback>$(AssetTargetFallback);netstandard1.3</AssetTargetFallback>
My theory was this would tell nuget to look for a netstandard1.3 version of automapper if it couldn't find a netcoreapp2.0 version. However, this didn't have any effect. I later read that behind the scenes this fallback is already added automatically.
If anyone has any ideas I would greatly appreciate it. I'm pulling out (what's left of) my hair on this, as this is the only package giving me trouble, and it's a critical one for my project.
On the build server I'm using .NET Core sdk 2.0.3 as well, if that matters.
This is how I solved this: since it seemed it might have to do with my target being netcoreapp2.0, I tried adding an additional 'dummy' project to my solution, with its target = netstandard1.3. In this configuration, the restore/build succeeded. I thought I would have to maintain this dummy project for this purpose, until I tried deleteing it and now the netcoreapp2.0 solution still restores fine without it. I can only assume something was corrupted in the TFS build server NPM cache (even though I had tried checking the box to disable that cache), and once I got it to succeed once, it has cleared up whatever the issue was.
I have an ASP.NET MVC 4 application. I used NuGet to update all of the NuGet packages that were installed when I created the application. One of the packages was Microsoft.Bcl.Build.
After updating these, NuGet displayed the following message at the bottom of its window:
I have since restarted Visual Studio several times, but the message still exists. When I checked the installed packages, it did appear that the updated version (1.0.8) of the package was present.
How can I fix this?
Instead of deleting all of ~/packages, see if there are any *.deleteme files in ~/packages and delete them. Then restart Visual Studio.
I believe this problem is caused by the packages being read-only or otherwise inaccessible at the file system level.
Packages under source control
Temporary work-around (untested)
Check out the entire packages folder prior to telling NuGet to restart Visual Studio to delete the packages.
Permanent work-around
I found that this could be permanently resolved by removing the packages from source control and instead using NuGet Package Restore.
Packages not under source control
Temporary Work-Around
I worked around this by deleting from the solution's packages folder all of the files that referenced the package in question. Specifically, these were:
Folder: Microsoft.Bcl.Build.1.0.7
File: Microsoft.Bcl.Build.1.0.7.deleteme
In my case, the relevant package folders remained in ~\packages, although they were empty. I deleted the folders and restarted Visual Studio, and this warning went away.
I've just deleted the folders of each package that had error in the Packages folder in my solution folder and also deleted the .deleteme files and everything works fine!
1) Delete the entire ~\packagesfolder.
2) Restart VS.
3) Go to Manage NuGet Packages and Restore
I'll agree that this can happen when your packages folder is under source control. If you like to have it there, instead of removing the bindings you can check it all out, remove the package with the NuGet Package Manager, and then check in after wards.
In my experience, I found my answer on this thread, but using a combination of a couple of different answers above so I thought I would share what I found.
I had the exact same issue with "Microsoft.Bcl.Build" as the original poster. I had been trying to update references for other functionality using NuGet and had issues with some of the updates (compatibility then rollbacks). After this NuGet failure, I started getting this error.
I initially used the selected answer and Jedidja's answer and was able to get this to work, but it only partially solved my problem. It did fix the VS restart error, but it caused a downstream issue with TFS as I could no longer check in the project as it was expecting that "*.deleteme" file. This got me thinking, so I did some testing. When I restored the file from recycle bin, I started getting the restart error again.
Here is where I deviated from the posted answers and got my full resolution to my version of the problem.
When I checked into TFS this time, the project checked everything in (after I got the projects all updated using NuGet while the "*.deleteme" file was deleted). Once it checked everything in, I noticed that file was still pending check-in so I checked the solution in again and TFS accepted that file, but it was as a deletion....assuming it checked in the first time and then VS auto deleted it which required the second check-in. Anyway....after the last pending change check-in, the file was gone and VS no longer complained about needing to be restarted. I can't say for sure because the problem is gone, but I get the feeling if I had checked the code in before deleting the file in the first place it might have solved the problem without manual file manipulation.
** Hi, everybody.**
i resolve this problem this ways.
If you have source control run the vs as administrator ( it is important )
in the solution packages -> delete thing about packages.
sample -> i deleted all entity framework version folders.
restart the vs
open solution and solution right click -> manage nuget packages for this solution.
you will see restore button :) restore
that is all.
If you are using Entity Framework 6, then you can install the NuGet package "EntityFramework.SqlServerCompact".
This enabled me to use the standard ASP.NET Identity tooling that comes with the project templates for 2013 and MVC5.
I am attempting to work through the N+1 TipCalc tutorial & get the following error when trying to compile the core project:
Error 1 Metadata file '1\packages\MvvmCross.HotTuna.CrossCore.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.CrossCore.dll' could not be found C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC TipCalc.Core
Error 2 Metadata file '1\packages\MvvmCross.HotTuna.StarterPack.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.MvvmCross.dll' could not be found C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC TipCalc.Core
Error 3 Metadata file '1\packages\MvvmCross.HotTuna.CrossCore.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.MvvmCross.Localization.dll' could not be found C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC TipCalc.Core
NuGet 2.5 RC was installed from here https://nuget.codeplex.com/
Profile104 xml files created as per instructions & have been used for a few weeks with V3 prior to attempting to use NuGet for the MvvmCross components.
Pre NuGet TipCalc tutorial was accomplished without problems.
Downloading the complete project from GitHub also compiles without issues.
I haven't been able to see any difference between the packages.config file in the downloaded project and the project being created from scratch.
The profile of the core project is also the same in each case.
The dll's are at the location indicated.
There were no issues with using NuGet to download the package, only when attempting to compile the project.
Any suggestions as to what I have missed?
TIA
My guess is that the problem is in your path
The path seems to be C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC
And the message is that '1\packages\MvvmCross.HotTuna.CrossCore.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.CrossCore.dll' could not be found
So maybe try using a path without an =?
I have an ASP.NET MVC 2 application.
Web project contains a reference to SomeProject
SomeProject contains references to ExternalAssembly1 and ExternalAssembly2.
SomeProject explicitly calls into ExternalAssembly1, but NOT ExternalAssembly2.
ExternalAssembly1 calls into ExternalAssembly2
When I perform a local build everything is cool. All DLLs are included in the bin\debug folder. The problem is that when I use the Publish Web command in Visual Studio 2010, it deploys everything except ExternalAssembly2.
It appears to ignore assemblies that aren't directly used (remember, ExternalAssembly2 is only used by ExternalAssembly1).
Is there any way I can tell Visual Studio 2010 to include ExternalAssembly2?
I can write a dummy method that calls into ExternalAssembly2. This does work, but I really don't want to have dummy code for the sole purpose of causing VS2010 to publish the DLL.
None of these answers are sufficient in my mind. This does seem to be a genuine bug. I will update this response if I ever find a non-hack solution, or Microsoft fixes the bug.
Update:
Doesn't seem promising.
https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I am having this same problem (different assemblies though). If I reference the assemblies in my web project, then they will get included in the publish output, but they should be included anyway because they are indirect dependencies:
Web Project ---> Assembly A ---> Assembly B
On build, assemblies A and B are outputed to the \bin folder. On publish, only assembly A is outputed to the publish folder.
I have tried changing the publish settings to include all files in the web project, but then I have files in my publish output that shouldn't be deployed.
This seems like a bug to me.
I had the same problem with VS2010 and a WCF Service Application.
It turns out that if your (directly or indirectly) referenced DLL's are deployed to GAC, the VS publishing feature excludes them. Once I removed the assemblies from GAC, publishing feature started working as expected.
I guess VS is assuming that if your assemblies can be located in GAC on the machine you build, they will be located in GAC on the target machine as well. At least in my case this assumption is false.
My tests show that the external assemblies get published when I have a reference on them in the web project. I do not have to write any dummy code to make it work. This seems acceptable to me.
I agree with Nicholas that this seems to be a bug in visual studio. At least it escapes me what the reason for the behavior could be.
I have created this issue as a bug on Microsoft Connect. If anyone experiencing it could vote it up https://connect.microsoft.com/VisualStudio/feedback/details/637071/publish-web-feature-not-including-all-dlls then hopefully we'll get something done about it.
If you go into the ExternalAssembly2 reference property list and change the "Copy Local" to "True" i think that might solve your issue.
I don't know if you are watching this still but I found the solution (I had the exact same issue) via this MSDN article. Under "build action" for the file choose "Content" that should include it in the list of files publish brings over.
I have created a new Connect bug here https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I've also attached a solution and detailed steps to reproduce this issue. Lets hope this time they won't close it as Can't Reproduce.
Vote for this connect issue if you experience the missing dll problem.
Copy local did the trick. I had an issue that the Newtonsoft.Json assembly get included in the deploymeny package. Copy local was set to false.
I am experiencing the same type of issue with a web project. I have a web project that references assembly A which references assembly B. It worked fine for some time but today it was broken. I did a rebuild of the solution and this time it deployed everything correctly.
I had this same problem today. I published my web project and realized that not all of the reference DLL's were there. In particular, the indirect DLL references.
It turns out that the directory in which I was publishing to was out of disk space (network share). I had just enough space to publish all the files except for few indirect reference DLL's. The sad part is that VS08 didn't throw any errors. It just published the files are usual. I cleared out some HDD space and everything worked fine.
I didn't find the HDD space issue until I tried to manually move the DLL's over.
in my case it is quite tricky.
Reference to ExternalAssembly2 is not required to Build the project but vital for run-time since we use reflection to configure Unity container.
So, I delete the reference - build the project successfully, but get run-time error.
If I preserve the reference I can Build and Run the application but I cannot Publish it with ExternalAssembly2 - get run-time exception as well.
This is happen because of internal VS2010 assemblies optimization.
So, what we can do here?
1. Put some unrequired peice of code to use any ExternalAssembly2's class.
2. escape from reflection and use static assemblies linking.
Hope this helps to smbd.
I got the same problem and this is a VS2010 bug if there's a reference link like:
Web Project --> custom project --> assembly1 -->(indirectly) assembly2.
For now I find if I reference the Assembly1 in the web project, then assembly2 is included in the bin folder.
So I had to add an additional reference link like:
Web project --> assembly1 -->(indirectly) assembly2.
Then VS can recognize assembly2 and include its dll file in publish action.
I have recently setup XAMPP 1.7.3 and ZendFramework 1.10.4 on a new computer and many of the commands that I normally use now fail.
Here are the steps I used to setup and test ZF.
First I added the ZF library folder (C:\xampp\php\ZendFramework-1.10.4\library) to the include path in php.ini.
Then I added the ZF bin folder (C:\xampp\php\ZendFramework-1.10.4\bin) to my Path system variable.
To test that everything is configured correctly I ran the command "zf show version" from the command line. The result is "Zend Framework Version: 1.9.6".
Immediately something appears to be wrong. The file that is downloaded is "ZendFramework-1.10.4.zip" and the reported version is 1.9.6. I have re-downloaded the latest version (1.10.4) and removed old copy. Still the incorrect version number problem persisted.
Having done some research there is a bug in the ZF knowledgebase that version 1.10.3 reports a wrong version number. So that may explain the version number problem.
Moving forward I tried to run some zf-tool commands and certain commands reports that the action or provider is not valid.
Example:
C:\xampp\htdocs>zf create project test
Creating project at C:/xampp/htdocs/test
C:\xampp\htdocs>cd test
C:\xampp\htdocs\test>zf create controller Test
Creating a controller at C:\xampp\htdocs\test/application/controllers/TestController.php
...
Updating project profile 'C:\xampp\htdocs\test/.zfproject.xml'
C:\xampp\htdocs\test>zf create action test Test
Creating an action named test inside controller at C:\xampp\htdocs\test/application/controllers/TestController.php
...
Updating project profile 'C:\xampp\htdocs\test/.zfproject.xml'
C:\xampp\htdocs\test>zf enable layout
An Error Has Occurred
Action 'enable' is not a valid action.
...
C:\xampp\htdocs\test>zf create form Test
An Error Has Occurred
Provider 'form' is not a valid provider.
...
Can any one provide insight into these errors and how to correct them?
I had a similar issue, it turned out that I needed to manually update the zf.bat and zf.php files that came included with xampp after updating to the latest zend framework.
I got them from the zend svn here: http://framework.zend.com/svn/framework/standard/trunk/bin/
the simple way if you are using xampp, just go to the path "xampp\php\PEAR" an replace the older Zend directory with all included files by a new one zend 1.10... dir and your porblems are lost :)
i think your problem is, that Zend Tool is shipped with xampp since some versions.
Try to find zf.bat in your Xampp directory and remove it ;)
ZF friends have written the worst kind of docs. For XAMPP user, it is more difficult. I have learning ZF and posting error getting on the path. I am also using XAMPP.
Your error list is very big. I hope I can help you.
Solution for error "An Error Has Occurred
Action 'enable' is not a valid action." is XAMPP's Zend Tool installation. Delete that.
Check here for more details about the solution and other possible errors: http://www.satya-weblog.com/2010/11/zend-framework-creating-layout.html.