I am using the BizTalk Deployment Framework (BTDF) to deploy my project and within that project is a pipeline component. The component appears to deploy fine, the dll in the Pipeline Components folder of the BizTalk install. However it does not show in the toolbox and any attempt to reset the toolbox crashes VS2010 which will not restart until the component has been removed ...
Anyone else come across something like this?
This appears to be a problem with the pipeline component wizard and the length of namespaces, class names etc. Shortening these seems to have removed the issue.
Related
We're just in the process of transitioning from VS2013&15/TFS2013 to VS2017/TFS2017 (on-site TFS, not VSTS) and the first test solution is a dotNet Core 1.1 based one (a multi-project web service).
The solution builds fine on the original developer's box and I've got it out of TFS and it builds fine on mine too. In keeping with our previous methodology the contents of the packages folder are checked in with the projects as this makes the packages locally available on the build box (no internet).
Building the solution on the build server is a different story, however, as I get multiple errors of the form...
..\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
This whole project.assets.json not found issue seems to be causing headaches all over. In my case the issue is that I'm trying to resolve it on our TFS 2017 Build Server, which does not and never will have internet access ('cos it's a server!).
All the solutions I've seen thus far seem to suggest running the Nuget Restore command but that can't work since the server cannot get to nuget.
This is nothing fancy yet, just a simple TFS 2017 Build definition with a Get sources and a Build solution step. I can't understand how something so simple has become so difficult.
Changing the Nuget Package Restore options makes no difference.
Since the project.assets.json files are generated on the fly in the obj folder, I can't even check them in to reuse. Can anyone please suggest a workaround, at the moment the test project is dead in the water.
Edit: trying the same process with a 4.6.1 web project created with VS2015 had similar results of unresolved references (e.g. System.Web) but didn't raise the same error, probably due to being an older, non-Core project.
According to I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
The issue seems not related to TFS build side since it also not work with local build through VS in the build agent machine.
Since this is a dotnet project. So, you could try to use “dotnet restore” and not “nuget restore”. Try using the dotnet core template (which uses dotnet restore).
If you are using authenticated nuget feeds, then you can use nuget restore but you also need to use nuget installer task. See https://github.com/Microsoft/vsts-tasks/issues/3762 for a discussion on that.
The Nuget version should be higher than 4.0.
Without dotnet restore and Nuget restore and only use get source/Visual Studio Build will not be able to build the dotnet core project. If your server do not have internet access, as a workaround you should use Local feeds.
When manually deploying a simple application from Visual Studio 2012 to BizTalk Server 2013 (i.e. right-click -> deploy) I receive the error:
Error 63 Failed to deploy map "<fully qualified map name>".
Error saving map. Stored procedure returned non-zero result. Check if source and target schemas are present.
This happens when I deploy the entire solution but not when I deploy each project individually.
I have found the link below which describes this error exactly and suggests installing a hot-fix, however this is specific to BizTalk 2010, not 2013. I have tried installing BTS 2013 cumulative update package 1 however this has not fixed the problem.
http://support.microsoft.com/kb/2673264
Any ideas what to try next?
I actually just went through this same deal.
Are you using a dll to reference a schema outside of your project? The issue with mine was that I was using an assembly to reference the schema in my map, but upon deploy that dll was not added to the project as a resource.
Manually add that assembly as a resource to your biztalk project, then redeploy the project with your maps and that should work.
If you are doing this on a VM, I would suggest taking a snapshot and try applying the Hotfix. If it works, I would run with it; if not, I would suggest rolling back the snapshot and raising a call with Microsoft via their Connect website indicating that the Hotfix KB2673264 addresses your specific problem, but does not work with BizTalk Server 2013.
The Microsoft Connect Website for BizTalk can be found at https://connect.microsoft.com/BizTalk.
You might also want to raise this question on the Microsoft MSDN BizTalk Forums: http://social.msdn.microsoft.com/Forums/en-US/home?category=biztalkserver
Add the assembly that contains the dll as a resource assembly in BiztalkApplication1 it worked for me
Verify that all the external assemblies are up to date in the application1 or simmilar common applications
This usually happens if you deploy binaries (msi) to new biztalk environment. This is due to source/target schemas (and any other reference assemblies) are not yet available on new biztalk environment.
You should also consider the script functoid components that are called on the maps.
Sometimes those schemas might be available on other applications. Try deploy those first.
Check your solution/properties, then configuration on the left.
From there you can click checkboxes of what needs to be deployed or not.
Make sure you are deploying the schema projects that the map is using.
(Or deploy the schema project first, then deploy the map project.)
In my case, the error was due to another non-deployed BizTalk project.
To be able to see where the "real" issue was, I used this solution : Greg Sharp blog
It allows me to find out that the project referenced in my current project was not deployed in BizTalk (Dlls was GACed so the build wasn't throw any error).
Check that all dependencies used in your project are GACed AND DEPLOYED in your BizTalk server.
I've a solution with several .dll projects, an Asp.NET MVC3 Razor project and an Cloud project.
If I try to compile the solution with the Cloud project loaded, VS2010 gets stuck in "Buil started".
I have to forcefully close VS2010 killing the process and restart. Then the compiling works good once, the next time it will get stuck again.
If I unload the project and set the mvc project as start-up, everything works (but azure of course).
What could be the problem?
Cheers.
Was it by any chance an ASP.NET MVC project to which you added a CloudService project later on or did you start off with a CloudService from the very beginning?
I was in the former situation and I had no end of problems, like not being able to open property pages or deploying the application. It's not quite your issue, but the following article might help:
http://tomkrueger.wordpress.com/2010/07/27/azure-deployment-issue-after-upgrading-to-visual-studio-2010-and-net-4-0/
As I say, my problems started because I actually added an Azure project to an existing ASP.NET MVC solution and there were some unnecessary settings left over in the web.csproj file.
All I had to do was open web.csproj in notepad and remove all occurrences of the <PlatformTarget> element.
My MVC prjoject was x86 and of course Azure works on x64 only. Even though I had the platform target set up as AnyCPU somehow Azure couldn't quite get along with it.
Maybe cleaning up your project files helps as well.
Perhaps I'm missing a setting here...seems like I am, but I cant see it!!
I have a deployment package, which works except...it deletes everything in the site that I am deploying to.
I have a web application beneath the site that I am deploying and I dont want that to be touched.
That has its own deployment package.
Any ideas?
Thx
Whenever I publish my MVC web application in VS 2010 via the One-click publish feature (I'm not doing any web.config transforms or anything fancy - yet!). The next time I come to build the app I get the following error:
It is an error to use a section registered as allowDefinition='MachineToApplication'
beyond application level. This error can be caused by a virtual directory not being
configured as an application in IIS. in ...MyWebApp\obj\release\package\packagetmp
\web.config
A new copy of the web.config file is indeed created by VS2010 below the ...MyWebApp\obj\ folder so I deleted the whole obj folder and I was then able to build again.
But I shouldn't have to do that each time I publish - I must have something configured incorrectly - can anyone help please.
Thanks.
This is unfortunately a known issue with Publishing a web application to the file system. This still affects the release version (RTM) of Visual Studio 2010. It's not limited to the Beta or RC versions.
This problem "bit" me also, and I too was having to manually delete the Debug and Release folders inside the obj folder within my web site solution folder.
The real answer for an automated "workaround" can be found in this answer to the other Stack Overflow question:
Why do I randomly get a “error to use section registered as allowDefinition='MachineToApplication'” when building an MVC project?
In a nutshell, you need to delete the web.config files from either the Debug or Release folders (or both!), and that's achieved with a pre-build command (configured in the Build Events tab of the Project Properties page of your solution):
del "$(ProjectDir)\obj\Debug\Package\PackageTmp\web.config"
del "$(ProjectDir)\obj\Release\Package\PackageTmp\web.config"
Personally, I delete the entire obj folder since all those files are re-created with each build anyway.
I have just found a work around for this that has worked for me, open the .csproj for your web project and change the node under the Project\PropertyGroup node to this:
from this:
<MvcBuildViews>true</MvcBuildViews>
to this:
<MvcBuildViews>false</MvcBuildViews>
This has worked for me, hopefully it will work for you also.