I've picked source code for an existing BizTalk 2013r2 solution that I'm trying to compile using Visual Studio 2013.
I'm hitting the following error when trying to compile a map:
Mapper Compiler: Functoid not found: guid
(2de6985a-3dff-46eb-a7d8-4fc884756860) with functoid id (54009). Check
if the assembly implementing this functoid is present
I've scanned all the source code I was provided with and there's no sign of any custom functoid classes. Maybe I'm missing a reference to an open source functoid library but from what I can see in the .btm file, there's not much to go on:
<Functoid FunctoidID="31" Functoid-FID="54009" X-Cell="44" Y-Cell="196" Functoid-CLSID="2de6985a-3dff-46eb-a7d8-4fc884756860">
<Input-Parameters>
<Parameter Type="constant" Value="ReceivedFileName" linkIndex="0" Guid="10eb4cb9-05b3-4e6e-b534-f3ee7ea8dadb" />
<Parameter Type="constant" Value="http://schemas.microsoft.com/BizTalk/2003/file-properties" linkIndex="1" Guid="e9119104-6fb3-43ef-9d17-ada0568dc557" />
</Input-Parameters>
Any ideas?
It sounds like you are missing a custom functoid. This is the reason I am not a fan of custom functoids. I prefer to put custom code in scripting functoids because it then goes with the map in source code.
That custom functoid does not appear in any of the searches, for example BizTalk Server: List of Custom Functoids (Technet). So I think you are on your own.
Look for a custom assembly in C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\Developer Tools\Mapper Extensions or as bts_dev says in the GAC.
Maps take reference from GACed assemblies, be it helper libraries or any other libraries. Custom functoids are also installed in GACed and then only can be added to tool boxes in Map editor.
Maybe on the source machine it was working as functoid assembly was deployed.
To resolve this issue, check the map project references and all referenced projects are building successfully.
There also may be a case of map assembly getting deployed when you tried to build the map project. But since it was deployed when VS solution was open it will not take reference to that deployed assembly yet. Try restarting the Visual Studio and open the solution again and then build the map project.
Related
When trying to open an older solution in VS2017 there is an old Unit Test project that is giving me a problem when building.
I keep getting the following error when building this test project:
Could not load file or assembly 'file:///C:\Projects\MyProj\Test\DAL\UnitTestProj\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' or one of its dependencies. The system cannot find the file specified.
I checked the project's references and it appears to be referencing Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. Additionally there are no code errors. How could I ever figure out if it is one of its dependencies that it can't find?
I had a similar issue (with the additional message The "BuildShadowTask" task failed unexpectedly) with a project originally developed with VS2010, and got to spend the last few hours learning about yet another legacy facet of the build process.
There is a good chance that you are dealing with private accessor files (.accessor), which were deprecated in VS2012 (original source). This was foreshadowed in an announcement from the VS2010 team that they were no longer working on these features.
There is also a chance you're just dealing with erroneous refs to the wrong version of UnitTestFramework, but a NuGet restore should fix this. If not, see this GitHub thread for a possible fix (manually change the ref to the public folder), or move to the new MSTest.TestAdapter and MSTest.TestFramework packages (see MSDN support thread).
Solutions
A. Edit the unit test .csproj and change the item Include references from Shadow => None:
<Shadow Include="Test References\namespace.accessor" /> to
<None Include="Test References\namespace.accessor" />
B. Better yet, simply delete all the .accessor files from the unit test project's Test References folder.
Ideally, you would also rewrite your unit tests to remove references to private methods, either by re-architecting to separate concerns or by changing properties to internal and using "friend" with the InternalsVisibleToAttribute.
For those who need to continue supporting testing of private methods for some reason, the same post provides the following suggestions to the logical question "What is available for me then?":
For those who wish to continue testing internal APIs, you have three options:
Use the Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject class to assist in accessing internal and private APIs in your code. This is found in the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll assembly.
Create a reflection framework that would be able to reflect off your code to access internal or private APIs.
If the code you are trying to access is internal, you may be able to access your APIs using the InternalsVisibleToAttribute so your test code can have access to the internal APIs.
However, there is not any good replacement for Code Generation for the new features added by the lanugage teams. You may create the TestMethod stubs and then remove the internal code. You only need to keep the stub itself.
Further reading / sources that helped me piece this together:
VS 2005 ASP.NET explanation of accessors
2008 blog article explaining how to work around this for build servers
MSDN forum thread with discussion on accessor purposes, implementations, and workarounds. Start about 1/3 down.
MSDN BaseShadow docs
MSDN PrivateObject class
Right click the project references folder. Add reference > Assemblies > extensions. Check Microsoft.VisualStudio.QualityTools.UnitTestFramework 10.1, and uncheck any older version.
This is related to Visual studio Enterprise 2015, add new load test was failing: and spiting as "Unable to find assembly 'Microsoft.VisualStudio.QualityTools.LoadTest, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
Due to Assembly installed in public assemblies shows as version 10.0.0.0 which is missed in GAC,
GAC had only 10.1.0.0. Once GAC updated with 10.0.0.0 and restart VS 2015. should resolve the issue similar to this.
Some more detail for better reasoning, System Assembly path and project path
DLL path
......\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
.CSProj reference version
I had a same issue while I was upgrading project to .Net4.8 in Visual studio 2022 earlier we were using Visual studio 2017.
Error:
The "BuildShadowTask" task could not be loaded from the assembly ***\Microsoft.VisualStudio.TestTools.BuildShadowsTask.dll. Could not load file or assembly 'file:///***Microsoft.VisualStudio.TestTools.BuildShadowsTask.dll' or one of its dependencies.
Solution : I removed ".accessor" files from project as that is being used for accessing private methods(most probably accessor is depricated). Then we used "PrivateObject" class for accessing private members in UnitTest.
Later we updated Unit Test case. Code references could be found from below articles.
Unit test private methods?
Unit Testing: Exposing Private Members
I had a similar issue (compile project in server Jenkins)
Solution:
Include VS.QualityTools.UnitTestFramework to reference project, whit Pakage Manager:
PM>NuGet\Install-Package VS.QualityTools.UnitTestFramework -Version 15.0.27323.2
https://www.nuget.org/packages/VS.QualityTools.UnitTestFramework
Try to fully uninstall Visual Studio 2017 (not repair). Then download the latest version and install it. Remember to check if MSBuild is added to installation files. Remember to delete folder inside Documents: Documents\Visual Studio 2017. In my case, this simple solution fixed all errors.
We've got a Windows 8.1 app that we've converted to a Windows 10 UWP app. The app works fine in debug, but when running in Release (.Net Native), we are getting a runtime error on app load. It's not at all clear what's causing the error. The error happens in the OnLaunched event in App.xaml.cs where some data is being initialized. The error:
An exception of type System.NullReferenceException occurred in
System.Private.CoreLib.dll
Additional information: Arg_NullReferenceException
We're using the latest versions of MVVM Light.
I know this isn't a lot of info, but it's really all we have right now and are pretty stumped. Anyone seen and issue like this or know where to start in tracking it down?
If, you're still using SQLite or any Reference.
Please Right Click to your Project => Add => Reference => Make sure your DLL of Nuget is checked.
Please Check this solution.
I had this exact problem in that I converted an 8.1 app to UWP. This was resolved by including a file called Default.rd.xml in the Properties folder. This was not mentioned in the migration guide that I had used.
Not including it means some pretty common coding patterns such as reflection will not work, and this includes in imported .dll's.
A basic Default.rd.xml file looks like the following ...
<!--
This file contains Runtime Directives used by .NET Native. The defaults here are suitable for most
developers. However, you can modify these parameters to modify the behavior of the .NET Native
optimizer.
Runtime Directives are documented at https://go.microsoft.com/fwlink/?LinkID=391919
To fully enable reflection for App1.MyClass and all of its public/private members
<Type Name="App1.MyClass" Dynamic="Required All"/>
To enable dynamic creation of the specific instantiation of AppClass<T> over System.Int32
<TypeInstantiation Name="App1.AppClass" Arguments="System.Int32" Activate="Required Public" />
Using the Namespace directive to apply reflection policy to all the types in a particular namespace
<Namespace Name="DataClasses.ViewModels" Serialize="All" />
-->
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
<Application>
<!--
An Assembly element with Name="*Application*" applies to all assemblies in
the application package. The asterisks are not wildcards.
-->
<Assembly Name="*Application*" Dynamic="Required All" />
<!-- Add your application specific runtime directives here. -->
</Application>
</Directives>
If this does not work, then try creating a new empty UWP project to get the latest format for the file.
We are updating a BizTalk 2009 application that I inherited. I'm converting them into BizTalk 2013 R2.
I get the following reasonably famous error, when I try to re-compile
Exception Caught: Cannot load source/destination schema: MyCompany.Schema.AppConfig.
Either the file/type does not exist, or if a project dependency exists, the dependent project is not built.
There are only two posts in SOF related to this error:
Biztalk Map Destination Schema Imports Multiple Schemas
Reference trouble with BizTalk schema project in Visual Studio 2008
and only a few meaningful posts in elsewhere.
The solution has 4 projects organized as follows:
Common (contains an 1 schema AppConfig.xsd file)
Orchestration (1 Orchestration file)
Schema (references an ASMX web service)
Map (1 map file, references Schema and Common Projects)
The Map project attempts to translate an source message of type AppConfig to the type AppConfigBE which is one of the Complex Types in the Web Service.
I keep getting the compile time error above.
Tried all of the following, as recommended in the two SOF posts, and a few other posts on MSDN forums, but none of it worked.
Tried alternating Copy Local on the Maps project (From true to false, and vice-versa)
Tried Replacing schema on source and destination on the map file
Schemas are referenced using fully qualified .Net type name
Tried referencing the .dll as opposed to the Schema and Common projects.
Updated the web reference; also removed and re-added the web references
Is there a solution/hot fix etc for this? Any other suggestions I can try?
UPDATE 1:
We had to call Microsoft for help; the engineer took my project file to try on their computers; he said they too had the same problem and as a fix, recommended to set the Build Action property of the .BTM map file to None instead of BTSCompile. After this, the project builds successfully. He said to test the project with this build and let them know. What I'm not sure is, what are consequences of this? Many topics on Build Action refers to the schema files, not the map files in a BTS project. What is the standard Build Action for Map files?
One more item is to clear any Assemblies from the GAC or re-GAC them with a Post-Build script.
I ran into the same problem. I needed to add
using Microsoft.XLANGs.BaseTypes;
using Microsoft.BizTalk.XLANGs.BTXEngine;
[assembly: Microsoft.XLANGs.BaseTypes.BizTalkAssemblyAttribute(typeof(BTXService))]
to the AssemblyInfo.cs into the project.
I just installed VS 2013, upgrading from VS 2010. Creating a web deployment package zip file used to work in 2010. using VS 2013's Publish Web feature to publish to a Web Deploy Package, I getting the following error:
Web deployment task failed. (Object of type 'manifest' and path
'D:\dev\DMWeb\DMWebClient\obj\Test\Package\DMWebClient.SourceManifest.xml'
cannot be created. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
The details in the Web Publish Activity tab shows the following:
Transformed Web.config using D:\dev\DMWeb\DMWebClient\Web.Test.config
into obj\Test\TransformWebConfig\transformed\Web.config.
Auto ConnectionString Transformed Views\Web.config into
obj\Test\CSAutoParameterize\transformed\Views\Web.config.
Auto ConnectionString Transformed obj\Test\TransformWebConfig\transformed\Web.config into
obj\Test\CSAutoParameterize\transformed\Web.config.
Copying all files to temporary location below for package/publish: obj\Test\Package\PackageTmp.
Packaging into D:\dev\DMWeb\DMWebClient\obj\Test\Package\DMWebClient.zip.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(3883,5):
Error ERROR_EXCEPTION_WHILE_CREATING_OBJECT: Web deployment task failed. (Object of type 'manifest' and path
'D:\dev\DMWeb\DMWebClient\obj\Test\Package\DMWebClient.SourceManifest.xml' cannot be created.
Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
Package failed.
In VS 2010, I've had to run it as Administrator for deploy to work, and I'm doing so here as well. I've also tried giving Full Control permissions to the project folder to NETWORK SERVICE, LOCAL SERVICE, Authenticated Users, and myself.
In the Package folder, there is the PackageTmp folder (which looks good), and the DMWebClient.SourceManifest.xml file, and that's it. In VS 2010, there's more files there.
DMWebClient.SourceManifest.xml contains:
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<IisApp path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp" setAclResourceType="Directory" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp\App_Data" setAclResourceType="Directory" setAclAccess="Write" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp/DMWeb.config" setAclResourceType="File" setAclAccess="Read,Write" />
</sitemanifest>
In VS 2010, the last line containing DMWeb.config doesn't exist. On top of that, the path to it is wrong. It should be under the App_Data folder.
DMWeb.config is specified in Web.config like this:
<appSettings file="DMWeb.config">
Any help would be greatly appreciated.
This can also happen if there are any files in your project that have been moved, deleted, or renamed from the file system such that Visual Studio doesn't know where to find them.
My error was allmost identical:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets
(3883): Web deployment task failed. (Object of type 'manifest' and
path
'D:\B\280\Binaries_PublishedWebsites\ProjectName\ProjectName.SourceManifest.xml'
cannot be created. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
The reason I found out is in the ProjectName.SourceManifest.xml file.
There is a line: <appHostConfig path="Default Web Site/ProjectName" />
If this webapp and site does NOT exist on the buildmachine, the error occurs. Once I created a dummy webapp site with the same name on the same site, it built!
And solved by removing that section with MsBuild parameters: /p:IncludeIisSettings=false /p:IncludeAppPool=false (i had those 2 to true, so only applies when you have them true)
Found out that I had an old .wpp.targets file from VS 2010, it was called ~DMWebClient.wpp.targets. In VS 2010, by renaming it, it would ignore it and not apply it. It seems like VS 2013 applies any .wpp.targets files regardless of the file name.
By removing that file, web deploy works again.
Thought I would add as none of the other answers fixed my problem, though perhaps more related to Lightswitch Web Deploy than ASP.NET Web Deploy (though OP doesn't specify which).
There are three projects within a standard Lightswitch Template solution. Two of them might be named lightswitchapp.HTMLClient and lightswitchapp.Server. Neither of these should be deployed! You should deploy the third project lightswitchapp.
I had been getting errors like this, which led me to this page.
Web deployment task failed. (Object of type 'manifest' and path 'manifest xml hidden' cannot be created. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
Great answer above, regarding the Lightswitch Web Deploy...couldn't find anything about it anywhere...kept thinking MS broke this on purpose because they don't want to support LightSwitch anymore...
In any case, once you go through the steps on publishing the main project from the LightSwitch template, a new problem arises, regarding the publish params if you push to a local IIS.
For all of you struggling with that...first install
httpPlatformHandler_amd64.msi
WebDeploy_amd64_en-US.msi
then, make sure "Web Deployment Agent Service" is running as a service
then, in Visual Studio (I am on VS2015 community), on the Publish Settings tab in the wizard, make sure you have something like this:
Service URL:
http://localhost/MSDEPLOYAGENTSERVICE
Site/Application:
Default Web Site\trax01
where trax01 is the name of your web app that runs under Default Web Site (please notice the back-slash before "trax01" compared to the forward-slash in the label for the setting.
Hope it helps somebody else, because this thing ate my liver! :)
The same exception can still happen in Visual Studio 2019. Additional detail for me was Object of type 'manifest' and path 'manifest xml hidden' cannot be created.
In my case the problem was a MsDeployDeclareParameters item in the {ProjectName}.wpp.targets file. It was attempting to set ACL permissions for the downloads folder, but the folder didn't contain any files so it wasn't present in the staging area.
Adding a file to the downloads folder resolved the problem (as would removing the MsDeployDeclareParameters entry from the {ProjectName}.wpp.targets file).
I tried many Solution by updating security to TLS 1.2 (X)
Removed * or special character from variables and password.
But later I found that, we have * in the password of connectionString in web.config.
I changed my password and it started working for me.
I have a WPF application in VS 2008 with some web service references. For varying reasons (max message size, authentication methods) I need to manually define a number of settings in the WPF client's app.config for the service bindings.
Unfortunately, this means that when I update the service references in the project we end up with a mess - multiple bindings and endpoints. Visual Studio creates new bindings and endpoints with a numeric suffix (ie "Service1" as a duplicate of "Service"), resulting in an invalid configuration as there may only be a single binding per service reference in a project.
This is easy to duplicate - just create a simple "Hello World" ASP.Net web service and WPF application in a solution, change the maxBufferSize and maxReceivedMessageSize in the app.config binding and then update the service reference.
At the moment we are working around this by simply undoing checkout on the app.config after updating the references but I can't help but think there must be a better way!
Also, the settings we need to manually change are:
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" />
</security>
and:
<binding maxBufferSize="655360" maxReceivedMessageSize="655360" />
We use a service factory class so if these settings are somehow able to be set programmatically that would work, although the properties don't seem to be exposed.
Create a .Bat file which uses svcutil, for proxygeneration, that has the settings that is right for your project. It's fairly easy. Clicking on the batfile, to generate new proxyfiles whenever the interface have been changed is easy.
The batch can then later be used in automated builds. Then you only need to set up the app.config (or web.config) once. We generally separate the different configs for different environments, such as dev, test prod.
Example (watch out for linebreaks):
REM generate meta data
call "SVCUTIL.EXE" /t:metadata "MyProject.dll" /reference:"MyReference.dll"
REM making sure the file is writable
attrib -r "MyServiceProxy.cs"
REM create new proxy file
call "SVCUTIL.EXE" /t:code *.wsdl *.xsd /serializable /serializer:Auto /collectionType:System.Collections.Generic.List`1 /out:"MyServiceProxy.cs" /namespace:*,MY.Name.Space /reference:"MyReference.dll"
:)
//W
Rather than changing the generated endpoint, uou could add a second endpoint and binding definition with the configuration you need, then in your code just put the name of the new endpoint in your service client constructor.
Somehow I prefer using svcutil.exe directly than to use the "Add Service Reference" feature of Visual Studio :P This is what we're doing on our WCF projects.
I take your point, svcutil is definetly the more advanced way of adding and updating service references. Its just a fair bit more manual work when "right click, update reference" is so close to just working in a single step.
I guess we could create some batch files or something to just output the reference code. Even then, manually checking out and updating the service code with svcutil will probably be more work than just undoing the check out on the config.
Thanks for the advice in any case.
What we do is we check out (from source control) the app.config and *.cs files that are autogenerated by the svcutil.exe utility, then we run a batch file that runs svcutil.exe to retrieve the service metadata. When it's done, we recompile the code, make sure it works, then check the updated app.config and *.cs files back in. It's a whole lot more reliable than using the oft-buggy "Add Service Reference" with Visual Studio.