I've created a basic map in BizTalk. No connections have been made. My input schema is a file within the same solution but in a separate project. The output schema is from a referenced .dll file (it is a very big schema).
When I go to build my project file, VS hangs (isolated this to the newly created map). When I go to validate my newly created map it will hang on invoking component....
I have checked the Windows logs and looked for error dumps but no such luck, just a simple devenv.exe stopped interacting...
I can't find any reference to this issue. Does anyone have any ideas or have encountered this issue?
Thanks.
Update:
I have isolated the issue to the referenced .dll schema that I have within my project. If I replace the schema with another referenced or local schema it will work just fine. I do not have the ability to edit this particular referenced schema unfortunately.
I have seen this when a Default Value is set either in the Schema or Map anywhere in a recursive structure.
Related
I have a U-SQL DB Project (USQLdb) that defines a U-SQL database and it's constituent tables, procedues, etc. This project also references two assemblies for use in one of the stored procedures. The DLL files are held within a folder called assemblies within the U-SQL Data Root folder and are referenced within the database using the following script:
CREATE ASSEMBLY IF NOT EXISTS [Microsoft.Analytics.Samples.Formats]
FROM "/assemblies/Microsoft.Analytics.Samples.Formats.0.0.0.0/Microsoft.Analytics.Samples.Formats.dll";
This works when deploying to Local-machine or to Azure.
For testing purposes, I have added a U-SQL Application Project (USQLScripts) that references USQLdb, with U-SQL scripts that execute a stored procedure each with the aim of setting up Unit Testing.
When trying to run these scripts against Local-project: USQLdb however, database deployment fails. From the logs it is because the USQLdb deployment script cannot find the referenced assemblies in the Local-project data root folder:
*** Error : (204,6) 'Assembly file 'C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot\assemblies/Microsoft.Analytics.Samples.Formats.0.0.0.0/Microsoft.Analytics.Samples.Formats.dll' could not be read.'
I have specified the USQLScripts Test Data Source as the local U-SQL Data Root folder which copies all files found to the Local-project working directory here:
C:\<Solution Folder>\USQLScripts\bin\Debug\USQLScripts_altdata_5qktnwfj.gln\data'
though per the error message above, the USQLdb Assembly Reference is trying to find them here:
C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot
As the DataRoot folder is completely cleaned and recreated on each Local-project execution, how can I either get the assemblies into the DataRoot folder on execution or reference them approriately without changing the address in the U-SQL script included earlier, which works as required when deployed to Azure?
Turns out, that if I remove the U-SQL Database reference in USQLScripts, the files that are in the Test Data Source folder are now copied to the C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot folder, but the scripts cannot execute as the database they are trying to execute against hasn't been referenced. I get the impression that I am either missing something or have hit a bug/unintended behaviour...
Turns out I was missing something.
What I thought was an error in referencing the assemblies was actually an error in building the USQLdb project, that resulted in the assemblies not being available and a red herring of an error being thrown.
The culprit was the Target Framework Version of the assemblies being higher than both the USQLdb and USQLScripts projects. It appears this can only be changed by editing the .usqldbproj files manually in a text editor (specifically the <TargetFrameworkVersion> value), as there is no option within the Visual Studio UI to edit this project property that I can find.
Once I upped the Target Framework Version in the U-SQL projects to match those of the assemblies, everything now builds, deploys and executes as expected.
I have made a new build definition. Most options are kept on default. I'm just playing around for the moment.
Problem is that when I build my projects as release mode in Visual Studio 2013 all is good, not errors. When TFS builds it I have a few errors:
(I had to translate it from my own language to English, sorry for that)
TemplateService.cs (80): Core.Infrastructure.Objects.PredefinedTemplate does not contain a definition for TemplateId and there is no extentionmethod TemplateId found gevonden *(something with first argument)* of the type Infrastructure.Objects.PredefinedTemplate is being accepted (possibly missing a user instruction or an assmbly-reference)
The things I already did:
Set the copy local of the referenced DLLs to false and true again, as stated on some websites
Check the build definition if it cleans the workspace (it does)
Added assembly names to the objects in code. I.e.:
PredifinedTemplate to Core.Infrastructure.Objects.PredefinedTemplate
Whatever I do, I keep gettings these errors! Does anyone know what is happening?
UPDATE:
As stated by James Reed I have placed the referenced projects in NuGet packages. In the end I had to place two projects in NuGet-packages. The build on TFS works now and it even deploys to the server.
Using NuGet is not my first choice, because of debugging functionality. But for these two projects, that only holds objects and data-entities, it should not be a problem.
You are missing an assembly reference. i.e. the dll containing the definition for TemplateId is not available on the build server.
If this is defined in a project in the same solution, then something is wrong with the project reference, try deleting and recreating the reference.
If this is a binary reference then you have 3 options
Add the project to the solution and use a project reference.
Check the binary in to source control (not recommended)
Use nuget to manage your references
I've got two files in my build named State.cpp. When I generate the VS project with the Introjucer and try to compile, both of those files clash to the same object file and I get the warning:
Warning 1 warning MSB8027: Two or more files with the name of
State.cpp will produce outputs to the same location. This can lead to
an incorrect build result. The files involved are
......\audio\State.cpp, ......\sg\State.cpp.
and then various link errors.
I can correct this easily enough within VS by modifying the Object File Name property on the VS project. However, when I regenerate the project with the Introjucer, that setting gets blown away.
Is there a setting I can use in the Inrojucer's config pages to prevent the clashes?
Just to close this one down...
There isn't. Rename the file for now.
We discussed this on the forum. I think Jules is up for making a change to the Introjucer to fix this - but it hasn't been done yet.
http://www.juce.com/forum/topic/msvc-build-consistency
http://www.juce.com/forum/topic/introjucer/visual-studio-2013-object-file-clashes
I have created a Silverlight class library which holds a lot of the common utility methods I use day to day in my Silverlight development.
I am starting to play around with Workflow and would like to reuse this common dll. After referencing this dll in my workflow project I see a yellow warning icon beside it.
I can use the functionality from this dll when creating ‘Code Activities’ without issue. After adding the using statement for it all works AOK.
using EquinoxeAISManagementSystem.Common.Helpers;
BUT when I try to import the dll from the activity designer, I do not see the dll in the import window.
If I edit the XAML and add it directly, I get a warning.
Is it possible to reuse Silverlight dlls?
I believe I can answer my own question.
The project EquinoxeAISMAnagementSsystem.Common is part of another solution. I had added this single project for the other solution into my new workflow solution (which I was having this issue in).
When I added the reference to the EquinoxeAISMAnagementSsystem.Common.dll initilly, it was by referencing the project in the workflow solution.
This seems to be the cause of the issue (for workflow anyway).
I was able to correct this issue by adding the EquinoxeAISMAnagementSsystem.Common.dll to a common folder where I keep all my external dlls (for ease of use).
..\Projects\EquinoxeAISManagementSystem.DLL\
I set up the output destination folder for this EquinoxeAISMAnagementSsystem.Common project to the folder above. I was then able to add the reference to Common.dll by browsing directly to the folder above.
Hay presto, all works.
I’m not sure id this is the ‘correct’ way to do things, but I needed to get over this hump.
I would be interested in anyone’s comments and if there is a correct(er), why to fix this issue.
Thanks ….
I'm trying to use Visual Studio 2010 to Add Service Reference to a service that I do not own. It does not add anything to the app.config, and the Reference.cs file that gets created only contains two classes, viz SerializableExpression and an empty InterLinqType class. But I don't have a usable client that I can instantiate.
When I turn off the option to Reuse Types in generated assemblies then it generates a bit more members in the above-mentioned classes, but still I have no usable client class that I can instantiate as my proxy to the service!
Using Visual Studio 2008 to add a Service Reference to the same service all works perfectly!
Please help.
I've had this issue in the past working with a 3rd party service.
3 things to try.
Download the WSDL locally and try to add it from there.
Create the proxy from the command line and then add it to your project. Here is more info on the command line util: http://msdn.microsoft.com/en-us/library/aa347733.aspx Play around with the flags that are available. Keep an eye on the /targetClientVersion flag. Here is a sample usage:
svcutil /t:code /language=VB http://servicedomain/serviceurl /out:MyServiceProxy.vb /config:MyServiceProxy.config
Validate the WSDL you are looking at is actually valid. I've had invalidate characters, unclosed tags, and invalid locations of extra dtd files throw off the creation of proxies. You can try and use the validator here to see if it fails here: http://xmethods.net/ve2/Tools.po
This is an old post but thought I would added my two cents on my solution.
I had the same issues as well. What I discovered is that my assembly references where not set correctly.
Issue: My test container is referencing my service reference and was only displaying my contracts not my service methods.
Resolution: I was referencing the assembly that contained my contracts. Once I removed it the references reappeared. Then I became curious and wondered if I could reference that assembly if needed without loosing my service reference. So, I readded that assembly I had removed in my references and then right clicked on the service reference and selected, "Configure Service Reference". I chose "Reuse types in specified referenced assemblies" and then only selected the system assemblies - i.e. did not select the assembly that is used in my service and referencted in my test - the only I originally removed to fix the issue. Every thing worked.
Summary: you have to play with the references a bit. This is how I fixed the issue in my project.