This is not covered by Unable to install custom connector in mule ....
I have been always been able to update Studio with the new versions of the custom connector using simple workflow of
Right-click on the connector project and select AnyPoint Connector -> Install or Update
Restart Studio
But, suddenly updates are not occurring. I've expanded to try
Clean connector project
Build connector project
AnyPoint Connector -> Install or Update
Restart Studio
Clean target project
Build target project
The changes are still not applied
I have also tried uninstalling the connector (and restarting Studio), but the target project still seems to find it even while the plug-ins-installed panel does not show it is installed.
I created a new workspace and imported the target project and the connector project into it. That did not help, but it did rule out Studio per se.
So I looked in the local maven repo and realized I had not updated by target project pom to use the newer SNAPSHOT version of the connector project.
Solved.
Related
I am new to apache cordova and i'm trying to build a client app for my asp.net mvc website, using apache cordova in visual studio.
but visual studio 2017 tools for apache cordova installs cordova 6.3.1 and some plugins like onesignal can't work on it.
Could you please help me?
That is a known issue but it can be fixed following these steps:
Assuming you have already installed Cordova 7.1.0 gobally using npm install -g cordova#7.1.0
In Visual Studio 2017 go to File > New > Project > Blank App (Apache Cordova)
Open config.xml in View Code mode and find this:
<vs:toolsetVersion>6.3.1</vs:toolsetVersion>
<engine name="android" spec="5.2.1" />
Replace with:
<vs:toolsetVersion>7.1.0</vs:toolsetVersion>
<engine name="android" spec="6.3.0" />
Where 7.1.0 is your global Cordova version.
Note how cordova-android has been increased to 6.3.0 as well.
Feel free to try using cordova-android 6.4.0 or cordova-android 7.0.0, however they may or may not introduce some issues (with Gradle for example). I have tested 6.3.0 but certain plugins may require a newer version.
Select Device as target.
Now Build > Build Solution
Save, close and reload the project. When you access config.xml in designer mode you'll see Global Cordova 7.1.0 as the selected toolset.
In order to build you may need to use the external Android SDK Build Tools (API 26) instead of the ones provided by Visual Studio (API 25).
Use the Android SDK Manager to manage versions, no need to get Android Studio for this.
Remember to follow the guidelines from Microsoft when changing the CLI on existing projects. However I strongly recommend creating a new one and then importing your files and adding your plugins to avoid potential problems.
I am trying to setup a CI build using Visual Studio Online but I am getting the following error about the NuGet client:
The 'System.Net.Http 4.0.0' package requires NuGet client version '3.0' or above, but the current NuGet version is '2.8.60318.667'.
Solution builds and deploys fine directly from my Visual Studio 2015 itself but I am unable to get it to build in VSO. Does anyone if NuGet 3.x is installed on hosted build controllers or if I can supply my own copy along with my solution?
It's hard to guess by the question what build tasks are used. If you use VSBuild/MSBuild, it is only possible to turn "Restore NuGet packages" on, but there's no influence on the NuGet version.
However, if you turn this checkbox off, and instead add another build task called NuGet Installer before the main build step, you'll be able to provide a custom path to NuGet.exe. In the case of hosted build agent, the most obvious option is to commit required version of NuGet.exe to the repo, and then reference it from the build step:
Sounds like a hack, but it might work in your case.
I've got a couple of ASP.NET vNext applications and I want my CI server to also be able to build them. Both my local machine and the CI server are running VS2015 RC. Then we've got VS Online and a local build controller - which is the server mentioned.
However, I cannot get builds going since it seems to be looking for v12 tooling - which does not include anything DNX.
So - building the solution gives:
The Dnx Runtime package needs to be installed. See output window for
more details
It is installed - since it came with VS2015 RC, AFAIK. So I thought the build template isn't using v14 tooling. I downloaded the Default Git template v12. And indeed it says:
<this:Process.BuildProcessVersion>12.0</this:Process.BuildProcessVersion>
So I switched that to 14, uploaded template, ran build. Then:
Exception Message: The build controller used for this build does not
support the version of the template file used by the build definition.
The version of the template file is 14.0. The maximum supported
version for this build controller is 12.0.0.0.
So trying to solve this - got me to this forum question that states:
Then, instead of changing the BuildProcessVersion property, you need
to change the involved MSBuild version. Open the build process template, find the Run MSBuild for Project activity, change the ToolPath property to the 2013 version msbuild
So - I checked out the template - there is no ToolPath version. There is a ToolVersion property however - which I'll try setting to 14:
In short, my question is: how can I build ASP.NET vNext apps on my build server, that has VS2015RC installed - but is building using v12 tooling?
UPDATE
Seems that the problem is not as much in using the wrong tooling, but more in finding/using the correct DNX runtime while running under a service account ( which the TFS agent is doing ). I've added an issue for the DNX team: https://github.com/aspnet/dnx/issues/2239 .
use msbuild parameter /p:VisualStudioVersion=14.0 ,which can be added in build definition .
I am trying to upgrade worklight project built using v6.1 to v6.1.0.01 and getting following error :
An internal error occurred during: "Upgrade Worklight Projects".
com.worklight.upgrader.versionGraph.VersionGraph.isKnownVersion(Ljava/lang/String;)Z
The version of studio is 6.1.0.01-20140418-0637
This could happen if your imported project is missing
either the complete org.eclipse.core.resources.prefs file in the .settings folder of your project (this is hidden file; you can see it using the Navigator view in Eclipse for example),
or if this file exists but it is missing the wl_version property.
You can fix this by creating a new project and copy over this file to your 6.1.0.0 project and then try to upgrade again to 6.1.0.01 - which you should be using 6.1.0.02 anyway by now and not 6.1.0.01.
One workaround you can do is to create a new project with the same name, etc in the Studio belonging to 6.1.0.01 and copy over your web resources and native code to the newly generated files.
You can also take a blank app in 6.1.0.0 and try to import that one to 6.1.0.01 to see whether it fails still or not. This will help in focusing the issue.
Thought I would try and get the most out of my visualstudio.com trial membership. I created a solution with a few projects, pushed it to the Microsoft git source control provider, configured a build definition and tried to build it on the project server. However it keeps failing telling me:
The type or namespace name 'Moq' could not be found (are you
missing a using directive or an assembly reference?)
I know this means that the build server can't find the Moq.dll library. I had installed it using NuGet, but configured my .gitignore to keep the packages folder out of source control. I also enabled NuGet package restore for the solution and pushed nuget.exe, nuget.targets, and nuget.config (all 3 of the files in the .nuget folder) along with all of the other project files.
Now I am sure I could get the build to work if I pushed the packages folder too, but I want to keep the nuget packages folder out of source control. So I am wondering, is this possible? The visualstudio.com docs say that the build servers have visual studio 2013 installed, and because of this I assume that nuget package restore would work to download the missing dll's so that they can be resolved by MSBuild. Is this right? Or to use automated CI builds at visualstudio.com, do you need to have your packages under source control?
According to the log file, nuget package restore downloaded the package. What gives?
Project "C:\a\src\MySln.sln" (1) is building
"C:\a\src\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj"
(3) on node 1 (default targets). RestorePackages:
"C:\a\src.nuget\NuGet.exe" install
"C:\a\src\Tests\MySln.ProjA.UnitTests\packages.config" -source ""
-NonInteractive -RequireConsent -solutionDir "C:\a\src\ " Restoring NuGet packages... To prevent NuGet from downloading packages during
build, open the Visual Studio Options dialog, click on the Package
Manager node and uncheck 'Allow NuGet to download missing packages'.
All packages listed in packages.config are already installed.
PrepareForBuild: Creating directory "obj\Debug\".
ResolveAssemblyReferences: Primary reference "Moq". C:\Program Files
(x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1635,5):
warning MSB3245: Could not resolve this reference. Could not locate
the assembly "Moq". Check to make sure the assembly exists on disk. If
this reference is required by your code, you may get compilation
errors.
[C:\a\src\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj]
This line is also in the build log file, below the above:
Considered "..\packages\Moq.4.1.1311.0615\lib\net40\Moq.dll", but it didn't exist.
I had this same error but it was occurring on our build server. I had added Moq via NuGet, checked in the project and everything was fine. I then moved the project into a new folder in TFS and the build server just couldn't seem to find Moq. It was building great locally. I ended up fixing the problem by making sure all of my changes were checked into source control and then deleting my local source code directory. I got latest and my test project realized it needed a new copy of Moq. I blame TFS/ source safe or what ever the Visual Studio integration module is for not adding it to source control at some point in time.
Figured this one out on my own. Turns out I had added the nuget packages before moving the test project into a Tests subfolder. The solution still built on my LM, probably because the dependencies were already copied to bin/Debug. After reinstalling the nuget packages, the solution built on vs.com.