I've just converted an interface from BizTalk 2010 to 2013. After conversion the schemas were not visible to the orchestration.
I turned off the compile option for the orchestration and it compiles perfectly.
I found the message(s) that were causing errors and tried to select the type but the schema types were not visible. Types in different assemblies were visible.
As a work around I created a separate project just for the schemas and moved them. I fixed the references to them in the original project and it works fine.
Did the ability to embed schemas in the same assembly as the orchestration change with BizTalk 2013?
Any suggestions how to fix this? I prefer having all the dependencies for an interface in one assembly.
Related
We have a BizTalk Pipeline which uses a custom pipeline component. There are various assembly versions of the pipeline component available and we wanted to know the version with which this pipeline was compiled with.
We loaded the pipeline in the resources (Add as BizTalk Assemblies and Resources, tried both ), but the dependencies tab does not show any component dependencies.
Tried with other Pipeline Projects as well to verify if this behaviour is exhibited by all other pipelines as well. And found it be true.
Is this an expected behaviour or am I missing something.
Version - BizTalk Server 2013 / Windows Server 2012
The same behaviour occurs in BizTalk 2013 R2.
It only shows which Send Ports or Receive Ports use the Pipeline, but the Using: section is blank and does not show you what Pipeline Components are referenced.
You can go the the Send & Receive Ports themselves and see the component names there, but that will not show you what version it is using.
If your different versions of the Pipeline Component have the same Strong Name Key and only differ in the assembly version number then it will either use the latest version from the GAC, or if not found in the GAC it will use the version in the Pipeline Components folder.
Also see this blog Find BizTalk Pipeline Component References
The hosting provider for one of the web sites I manage has forced us to only be able to modify the site as a web project instead of as a web application. When it was initially a web application it was working fine, but after converting to a web site project I had many issues involving missing namespaces and references and was able to resolve them by placing all of my libraries inside of the top-level App_Code folder of the web site. I have one last issue with my linq-to-sql class - in Visual Studio the class is recognized now that it's in the top level App_Code folder, but when I call a page which references it I get the following error:
The type or namespace name 'LIFH_IntakesDataContext' could not be found (are you missing a using directive or an assembly reference?)
Initially there was no namespace whatsoever, but in my attempts to fix this I addded a "LIHS" namespace and placed the Data Context within that:
Here are the references for the site:
And here is the Build configuration:
And, here is my directory structure (Linq-to-SQL class is referenced in the circled "reports.aspx" page):
Code in reports.aspx:
Both the master page and the reports page are both in the LIHS namespace.
I am developing on Visual Studio 2012 and the application pool is set to .NET 2.0. The hosting provider does not allow anything above 2.0.
I have researched and found many references to my issue but most of them solve the problem by converting to a web application, which I cannot do, or by changing the target framework or by using a namespace, which I have done, but to no avail. I would appreciate any insight on this.
Pay Attention: Linq is only available in .Net 3.5 and later
If you are using .net 2.0 it wont work.
You can see it in your screenshot.
Hope it helps.
Mike
I'm using Visual Studio 2013 and MvvmCross to create an Android application using Portable Class Libraries.
I notice in my first view model, CatalogViewModel, some code is highlighted as not referencing the correct assemblies or unable to be resolved (the code builds fine even with these issues).
Examining the .NET Portable Subset assembly in the Object Browser shows various System assemblies included (2.0.5.0 v2.0.50727 & v4.0.30319, 4.0.0.0, 5.0.5.0). Automatic binding redirection for assemblies in .NET Framework 4.5.1 can be enabled or disabled by adding this line to the .csproj file.
<AutoGenerateBindingRedirect>true</AutoGenerateBindingRedirect>
or
<AutoGenerateBindingRedirect>false</AutoGenerateBindingRedirect>
This seems to solve the referencing and redirection issues in the IDE. I haven't found any information about this manual modification to the Core project file in any of the MvvmCross info online I reviewed so I wanted to post a question here to see if anyone had some information or best practices.
No, you shouldn't need AutoGenerateBindingRedirect. This feature is intended to generate binding redirects for non-platform assemblies, such as NuGet packages. Platform assemblies should be unified automatically by Visual Studio / MSBuild.
Which seems to work, since you pointed out:
the code builds fine even with these issues
So this looks like a bug in ReSharper. The fact that adding AutoGenerateBindingRedirect fixes your ReSharper issues might be a side effect of something else.
I am getting a build error when I attempt to build my asp.net application. The error is:
The type 'MediCare.Framework.Authentication.IUserAuthenticate' is defined in an assembly that is not referenced. You must add a reference to assembly 'MediCare.Framework, Version=1.0.1.95, Culture=neutral, PublicKeyToken=1999fa3c42b9'.
I can see the class in the library which is in the references folder. How do I debug this issue?
My intention is to point the references folder to the library source code's bin directory (since the pdb file is lcoated there and any updates to the library will reflect in the application). However, when I point the references folder to the bin directory of the source code, I get the error message above.
Update The application was originally developed in VS 2008 and I am modifying it in 2010. I think I am confused about where the GAC assemblies would be, if I am using VS 2010 (2.0 framework location or 4.0 framework location) ? .NET 4.0 has a new GAC, why?
Update (06-26-2012)
The file in the GAC ("C:\Windows\assembly\") has been deleted. But this error is still occuring.
This could possibly be caused by version inconsistencies. Meaning, in order to fix this, I would do a complete clean build of your assemblies (and also an assemblies that might be nested inside an assembly). Just go out cold and do a new build on all assemblies. That should work.
Go into windows explorer, right click on the DLL file that your project is using that contains this class, and look at the version tab. Make sure version number matches what you see in the error message. My guess is that it won't.
If it does match, then check the GAC and make sure there isn't a different version of the DLL there that it could be picking up. To do that, go to windows explorer, and navigate to c:\windows\assembly. See if that assembly is in there with a different version number. If it is, you may need to delete it from the GAC (use caution though because other apps may depend on it being there).
I have to call functions from a custom dll from BizTalk orchestrations (similar to this solution Call a custom .NET component from BizTalk 2006). The dll calls functions of a third party dll, which uses some other third party dlls (we are using to communicate with a legacy system).
The article Global Assembly Cache Tool (Gacutil.exe) says that my best bet would be to "include" the referenced dll into the dll I put into the GAC, but I don't know how to do this from Visual Studio (2010).
Any ideas to get this work ?
It looks like putting them into the system PATH solved this problem.