I'm struggling to find any meaningful information on this issue so any thoughts would be greatly appreciated.
I have a SSIS 2016 package that has a Visual Basic Script Component that requires connectivity to a remote Informix database via an ADO.Net connection. The necessary project reference to the IBM.Data.Informix.dll has been added and the project builds without error. However when the package executes a runtime failure occurs:
"Could not load file or assembly 'IBM.Data.Informix.4.0.410.02, Version=4.0.410.2, Culture=neutral, PublicKeyToken=7c307b91aa13d208' or one of its dependencies. The system cannot find the file specified.":"IBM.Data.Informix.4.0.410.02, Version=4.0.410.2, Culture=neutral, PublicKeyToken=7c307b91aa13d208"
I have tried some of the suggested solutions I have come across including setting the reference property, "Copy Local = False" as well as repointing the reference to the various versions of the installed dll. File locations include the GAC, "C:\Program Files\IBM Informix Client SDK\bin..." and "C:\Program Files (x86)\IBM Informix Client SDK\bin...". Both 32 and 64 bit versions are installed and the dll files do exist in the referenced locations. All attempted solutions failed.
Any suggestions where I can go to from here?
Thanks in anticipation.
I have a old solution which worked fine with VS 2012 and now I migrate it to VS 2013.
When I try to build a configuration which involve web.config replacement i got this error:
Error 1 The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
What it mean is that there no build tools in my v11.0 which is right. Because I use Visual Studio 2013. (the build tool are in a folder called v12.0) One option is to just copy my build tool to the right place but im searching for a real solution.
I found in my .csproj file these config:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
But im not really understand why it then v11.0 could be. I have tried multiple things to change these like set VisualStudioVersion explicit but it changed nothing.
So my question: where the heck come these path from and where can I configure it?
Since vs2012 MS tries to keep sln file untouched if there is no reason to upgrade it (to allow opening sln in the old VS).
If you’ve upgrade from vs2012 to vs2013 there can be chance you are opening solution in vs2012 (it happen to me in many updated solutions).
Try to check beginning of the sln file
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
or:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
If you wish to change it by VS, open sln in vs2013 and then select solution root node in solution explorer and the File > Save .sln (Ctrl+S)
I am attempting to add a custom “activitycode” to a TFS Build. I wrote this months ago and had it working on a now defunct test environment. I am attempting to resurrect the use of the code onto a new test platform, and am running into issues.
When I open my build.xaml, I receive the dreaded red-box of pain where my custom activity should be, stating “Assembly could not be loaded because of an error in the XAML.” In the ErrorList, I also have found “Could not find type '.DeploySSRSReportActivity' in assembly 'ReportingServicesDeploy'.”
I have confirmed that my DLL is checked into source control and that the build controller is pointing to it.
Peeking into the raw XAML, I see that the build.xaml file defines the assembly as
xmlns:rsd="clr-namespace:;assembly=ReportingServicesDeploy
The line where my custom activity (and where V.S. finds the error) is:
<rsd:DeploySSRSReportActivity CurrentBuild="[BuildDetail]"
SourcesDirectory="[SourcesDirectory]"
mtbwt:BuildTrackingParticipant.Importance="High"
xmlns:mtvc="clr-namespace:Microsoft.TeamFoundation.VersionControl.Client;assembly=Microsoft.TeamFoundation.VersionControl.Client"
xmlns:mtvco="clr- namespace:Microsoft.TeamFoundation.VersionControl.Common;assembly=Microsoft.TeamFoundation.VersionControl.Common"
xmlns:ras="clr-namespace:ReportingServicesDeploy;assembly=ReportingServicesDeploy"
xmlns:rsd="clr-namespace:;assembly=ReportingServicesDeploy"
xmlns:sad="http://schemas.microsoft.com/netfx/2009/xaml/activities/presentation"
xmlns:sad1="clr-namespace:System.Activities.Debugger;assembly=System.Activities" />
The DLL is named ReportingServicesDeploy.dll. The namespace within the DLL is ReportingServicesDeploy, and the name of the activity class is DeploySSRSReportActivity.
Where is the linkage failing so that I am getting that error?
When your attempting to edit the xaml your doing this on your machine directly, tfs and sourcecontrol is not involved, the location on server for controller is where build agent will look for assemblies during the build and where VS will get them when opening build definition for config.
Your error possibly is coused by old version being used.
The assemblies must be available for visual studio on your machine - one option is to add them to GAC or to post in VS bin folders. Start new instance of studio afterwards
To intall into GAC run this from Visual Studio command line:
gacutil /i "Path\To\YourAssembly.dll"
To remove assembly run following from Visual Studio command line:
gacutil /u "YourAssembly"
For studio assemblies i believe this is the folder:
Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
I am using the reportviewer control from VS 2010 to create client side reports (rdlc). Everything is working fine on my development machine, and when I manually compile (via VS2010) and manually deploy to a test machine that doesn't have development tools installed.
In order to get the test machine to work (without installing VS2010 or ReportViewer.exe), I had to add references in my project to Microsoft.ReportViewer.Winforms, Microsoft.ReportViewer.Common and Microsoft.ReportViewer.ProcessingModel and have them all "Copy Local".
I have the rdlc files configured for Build Action => embedded resources. This is the default setting when adding a new rdlc to the project. I am open to configuring this otherwise if this would resolve this problem (no idea if its related).
The problem: since adding the rdlc files, the solution no longer builds on the build server. I have installed ReportViewer.exe on the build server, and have verified that the required assemblies exist in the GAC. The .Net 4 framework is NOT installed on the build server--I don't think this is required because the solution targets the 3.5 runtime.
I believe the root of the problem is the following from the build log:
Target "RunRdlCompiler": Building
target "RunRdlCompiler" completely.
Output file
"obj\Release\RdlCompile.compiled" does
not exist. Using "RdlCompile" task
from assembly
"Microsoft.ReportViewer.Common,
Version=9.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a". Task
"RdlCompile":
Report\RDLC\GreenReport.rdlc (0,0):
error rsInvalidReportDefinition: The
report definition is not valid.
Details: The report definition has an
invalid target namespace
'http://schemas.microsoft.com/sqlserver/reporting/2008/01/reportdefinition'
which cannot be upgraded.
From what I can tell, Microsoft.ReportViewer.Common version 10.0.0.0 is what should be used to "compile" the rdlc, but MSBuild appears to be using 9.0.0.0. I believe if I could force it to use the right version (which IS installed in the GAC), the solution would compile.
This is because your Microsoft.Common.Targets file is pointing to the 9.0 version of the assembly.
If you look in [sysdir]\Microsoft.NET\Framework\v3.5 you will find Microsoft.Common.targets, which is driving a lot of what MSBuild does. This verion of the common targets file points to [Program Files]\MSBuild\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets forcing MSBuild to run with the 9.0 version.
When you installed .NET 4.0, you got a new common targets file in the v4.0.x directory, this new one now points to [Program Files]\MSBuild\Microsoft\VisualStudio\v10.0\ReportingServices\Microsoft.ReportingServices.targets which points to the 10.0 version of the ReportViewer assemblies.
The 10.0 ReportViewer is compiled against .NET 3.5 and intended to work in both 3.5 and 4.0. You could very likely get rid of the .NET 4.0 framework, and alter your 3.5 common targets file to point to the new ReportingServices target file, and it should work. In theory anyway, I've never actually tried it. You may be best off just sticking with 4.0, as that's what we intended when we designed the MSBuild support for the new viewer.
Just install Microsoft Report Viewer 2010 SP1.
I had a very similar issue. Just all of a sudden I could no longer build a VS2010 project that contained an .rdlc file. I wasn't converting any reports or using a report server, everything was local. I tried creating a brand new project and adding an empty new rdlc report and hit build and it wouldn't work. Just one day it stopped compiling and gave me the following error:
The report definition is not valid. Details: The report definition has an invalid target namespace 'http://schemas.microsoft.com/sqlserver/reporting/2008/01/reportdefinition' which cannot be upgraded.
Turns out the issue was my "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\ReportingServices\Microsoft.ReportingServices.targets" file had somehow changed. The top of my file was:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
And it should have been:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
I changed that one "Using Task" line in the file and everything builds again. REALLY frustrating and it ate up two days of my life. Hoping posting this comment may help someone else in a similar situation.
Jim Lafler
I have tried re-installing all and it didnt work. Then, I tried updating Microsoft.ReportingServices.targets as per Jim's post but even didnt work for me.
At the end, I just copied Microsoft.ReportingServices.targets from other machine (where it was running without error). And surprisingly, it is working.
The additional difference I noticed while comparing, to change PublicKeyToken along with Version.
This may be the case for me only but Jim's post was much useful.
SFUH
Turns out I did need the .Net 4.0 Framework, and more specifically the 4.x version of MSBuild, which uses the newer version of the Microsoft.ReportViewer.Common library.
So even if you are targeting the 3.5 framework, if you create the rdlc with VS2010 it will expect to be "compiled" using 4.0 tools.
I have the same problem: we using ReportViewer 2012 (version of assemblies starts with 11). Both on local machines and on build machine are installed ReportViewer 2012 package and VisualStudio 2013. On local machines compilation in VS succeeds, but on build machine during queued build MSBuild throws such error:
The report definition is not valid. Details: The report definition has an invalid target
namespace 'http://schemas.microsoft.com/sqlserver/reporting/2010/01/reportdefinition'
which cannot be upgraded.
I tried to modify Microsoft.Common.targets from .NET 3.5 folder in way, that is described in this post, but no effect. Then I opened Microsoft.Common.targets from .NET 4.0 folder, and found there such strings:
<!-- VS10 without SP1 and without VS11 will not have VisualStudioVersion set, so do
that here -->
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)'
==''">10.0</VisualStudioVersion>
</PropertyGroup>
Then I realized that problem may be in incorrect value of variable $(VisualStudioVersion), so I added to build definition in section "Process" this MSBuild parameter:
/p:VisualStudioVersion=12.0
And it worked! Build completed successfully.
Hope this will help someone.
Pasting file paths doesn't seem to be going through... how about this:
Was:
TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.Common, Version=8.0.0.0...
And is now:
TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=10.0.0.0...
James
The NetFx40_LegacySecurityPolicy was enabled in my devenv.exe.config, and when I commented this line out, the project built successfully.
We had enabled the legacy security policy on our team to enable our team to work with DevExpress 7.2 controls from within Visual Studio 2010, but in this case, it shows that the approach we took is not always the best.
I lost 2 full days of development due to a similar issue. On building my project it would succeed, but on rebuild it failed with no errors. On investigating the verbose build log in the Output window it directed me towards a problem with the rdlcompile function (so reporting services local report embedding issue). After trying every thing I finally manage to resolve the issue, but disabling my virus scanner. The Antivirus was somehow interfering with my rebuild and caused the rebuild to fail.
After disabling virus scan, rebuild works 100%
I have same problem on my Visual Studio 2013.
The dll version of reporting service on my project is Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
When i checked my ReportingServices targets
C:\Program Files\MSBuild\Microsoft\VisualStudio\v12.0\ReportingServices\Microsoft.ReportingServices.targets
I found the task version is 11.0.0.0
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>
When i changed the task version to 10.0.0.0 corresponding to dll version on my proejct.
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
It' worked.
I just removed this file from my file system. The reports are simply ambedded no need to be compiled.
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\V11.0\ReportingServices\Microsoft.ReportingServices.targets
this worked fine for me and for my build server.
I tried to convert a project that relies on the vjs runtime to vs2010, but it errors out when trying to run.
It's giving the error that "Could not load file or assembly 'vjslib' or one of its dependencies. An attempt was made to load a program with an incorrect format."
I reinstalled the vjs runtime, but it didn't seem to help.
Is there any way to get get .net 4 to work with this?
Very simple solution - Calling J# code from .NET 4.0
You take control and load it first supplying an explicit path. Then next time it's needed, it already knows the path (or it's already loaded in the AppDomain).
You will need to use LoadLibrary function, so import the pinvoke reference:
[DllImport("kernel32", SetLastError = true)]
static extern IntPtr LoadLibrary(string lpFileName);
The on load (either Main function in Console/WinForms or in Global.asax Application_Start):
if (Environment.Version.Major >= 4)
{
string folder = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), #"..\Microsoft.NET\Framework\v2.0.50727");
folder = Path.GetFullPath(folder);
LoadLibrary(Path.Combine(folder, "vjsnativ.dll"));
}
I have downloaded Microsoft Visual J# Version 2.0 Redistributable Package from http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=4712 and installed it.The issue is resolved.
I got this to work by copying C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\vjsnativ.dll (for 64 bit Microsoft.NET\Framework64\v2.0.50727\vjsnativ.dll) to my application's debug/release directory.
I suspect Microsoft will need to release another j# redistributable package to work with .net 4.0. Meanwhile, this work-around does a fine job.
The only way I could get it to work was to copy the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\vjsnativ.dll to the C:\Windows\Microsoft.NET\Framework\v4.0.30319 folder. See http://community.microfocus.com/borland/managetrack/starteam/w/knowledge_base/17108.error-unable-to-load-dll-vjsnativ-the-specified-module-could-not-be-found-exception-from-hresult-0x8007007e.aspx
To add to the existing answers, I found that the solutions didn't work for me.
First thing I did was to repair the Microsoft Visual J# 2.0 Redistributable Package -SE (x64) using Windows Control Panel (Just right click and click repair). This was in case I did any damage in my previous attempts to fix the problem.
I had already implemented the solution provided by David Thielen.
1 Extra step closed the deal for me (solved the problem):
Copy "vjscor.dll", "vjslib.dll" and "vjsnativ.dll" from C:\Windows\Microsoft.NET\Framework64\v2.0.50727 To C:\Windows\Microsoft.NET\Framework\v2.0.50727
So basically the Microsoft package placed the correct dlls into the 64-bit .NET framework and I had to manually move them into the 32-bit folder which is then copy-pasted into my solution folder by David Thielen's solution (above).