I'm developing some reports in SSRS 3.0, and I've hit a snag. I've got a .NET method that I need to call, and I can't get it to work. I've found a few "how to" websites that purportedly explain the process, but I can't seem to make it work. As a first experiment, to just prove I can do this, I've written a little "HelloWorld" program that just returns two strings concatenated together with a space between:
using System;
namespace HelloWorld
{
public class Hello
{
public static string SayHello(string hello, string world)
{
return hello + " " + world;
}
}
}
I've got the reference defined in the Report Properties / References tab; but when I try to run it, I get
Error while loading code module: ‘HelloWorld, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’. Details: Could not load file or assembly 'HelloWorld, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
I've copied the DLL to numerous suggested locations:
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\Reporting Services\ReportServer\bin
The folder with the RDL file
Nothing seems to work.
I've seen reference to editing the rssrvpolicy.config file; but my system doesn't have one. I could create it, but I don't know where to put it.
I'm using Visual Studio 2010, Report Builder 3.0, and SQL Server CE (I have SQL Server installed on my dev machine as well; but it will not be on the target machines). We will not be using a Report Server -- the target machines are all standalone, and very few will have network access.
If there's any other information I can provide, please let me know. And thanks for any suggestions you may have.
Sounds to me like a mixed DLLs CPU architecture issue.
How do you compile your DLLs (x64, x84 , AnyCPU)?
Try to match the DLLs to correct CPU architecture of the server. then clean solution and compile it with as debug or release (that doesn't matter).
Make sure to clean all copies of previous DLLs , before copying the new ones. (just to be on the safe side)
Let me know if that works for you...
Related
I have several projects made in Visual Studio 2010, those projects are ArcGIS Desktop Add-in's. I have been change of computer, and my new one only have Visual Studio 2013 due to some company politics I'm not allowed to install VS2010.
I tried to open this projects in VS2013, and they open with no problem, but when i try to compile it, it get me the following issue:
ESRI.ArcGIS.AddIns.SDK, Version=10.2.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86. Could not load file or assembly 'Microsoft.VisualStudio.Shell.9.0, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' 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.
my research so far has get me to install the VS SDK, but I'm not quite sure about which one(2008...2013)
Any one has any possible solution for this?
First, I check that Microsoft.VisualStudio.Shell.9.0 was in the GAC, It was not there... :( then I proceed as Juho Vainio in Geonet suggest : Visual Studio Command Prompt --> Run as Administrator --> gacutil /i Microsoft.VisualStudio.Shell.9.0.dll, but it failed because I was not giving the full pat of the dll, so I search for it in the Visual Studio 2008 SDK, and Voila!!! it appear in the GAC
but the project still does not compile, so, I chec in the real GAC:
C:\Windows\Microsoft.NET\assembly
and found that the file does not exist neither in the GAC_32, nor GAC_64 folder, moreover, it exists in the folder GAC_MSIL, so....i took the folder C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.9.0 and copied it to the folders GAC_32 and GAC_64.
Now the project compiles.
I have the following scenario:
Visual Studio 2010 solution with one WPF-project, output file is "Tool.exe"
Eclipse Shared Library project, output file is "Tool.dll"
I place the dll in the same folder as the exe and then I try to debug using Visual Studio; but I get the following error:
Error while trying to run project: Could not load file or assembly 'Tool' or one of its dependencies. The module was expected to contain an assembly manifest.
I have managed to find a solution to the problem, rename the dll, apparently the exe and dll cannot have the same name. My question is, why is this error occuring in the first place? Why does the name of the dll affect Visual Studio? The error occurs before even trying to pinvoke the dll. If I run my application without Visual Studio it works perfectly, but I want to be able to debug it of course.
Right now renaming the dll is plan B, but before I do that I would like to know if there is anything else I can do to fix this problem?
Thanks in advance.
I found simple steps to solve this error.
1- change your windows.
2- install Symantec Endpoint Protection Client 12.1.6318.6100 x32 or x64 bit.
You can geting it software(32 bit) from link: (ftp://192.168.168.215/Public/Antivirus/Symantec/Symantec Endpoint Protection Client 12.1.6318.6100 x86.rar)
drag and drop it to your software(IE ,....) to work.
3- install all driver on your computer.
4- install Visual studio.
End
I am using Visual Studio Team Services as source control and have enabled continuous integration.
My project is an ASP.NET application which used Entity Framework 5. When i checkin the code and the build controller tries to build it, the following errors come up
DataModel\GenomicsTutorDataModel.Context.cs (40): The type or
namespace name 'DbSet' could not be found (are you missing a using
directive or an assembly reference?)
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
(1578): Could not resolve this reference. Could not locate the
assembly "EntityFramework". Check to make sure the assembly exists on
disk. If this reference is required by your code, you may get
compilation errors.
In my solution i have made system.data.entity CopyLocal = True yet no success.
Any ideas?
May be you are on a 64 bits machine and the TFS server is not?
Try to build your project for Any CPU or x86.
Add the DLL you referenced for System.Data.Entity into a folder in your project or somewhere in a folder in the Source Control and reference to that one. Check this in and try to build your application again.
I'm not a a very experienced Windows developer, so I hope this all makes sense.
I created a Managed Assembly DLL using Visual Studio 2010. The DLL (Plip.dll) contains a C++ class that is using System.IO.SerialPort class to do some simple communication over a serial port.
In a second Visual Studio project I created a simple GUI that uses the class found in Plip.dll. In my GUI project I have the line : #using "Plip.dll" . In the Project Properties I set the 'Resolve #using References' value to the correct location of Plip.dll. The GUI builds just fine. If I copy the GUI.exe and Plip.dll to the same folder, the GUI runs just fine on my computer.
The problem I am having is that when I copy both files to a second computer, I cannot get the GUI executable to run. I get the following error : "System.IO.FileNotFoundException. Could not load file or assembly "Plip.dll" Vesion=.... ". I get this error even though both the exe and dll are located in the same folder.
Any suggestions on how to resolve this issue? Is there some option I need to set in my GUI project to load the DLL correctly at run time?
I suppose the problem is not the Plip.dll, but it's dependencies.
Use Dependency Walker on the second computer to see if it needs any other dll's (they might be installed in System folder or in %PATH% on your development computer, but not on the other).
If this second computer doesn't have Visual Studio installed, you are probably missing Microsoft Visual C++ 2010 Redistributable Package (you need to install it on the other computer)
Also make sure that you compile in Release because debug builds need debug dependencies.
I found the answer to this problem to be much simpler than Dependency Walker (but admittedly, that was fun to look at).
In my case, the issue was a mis-match between the .DotNet versions in the DLL and with the application's .net version. This was caused by building the "class library" using .DotNet 6.0 (dot net core?).
Instead, the entire class needed to be re-built using "Class Library (.NET Framework)"
enter image description here
I wrote an article on this problem.
https://keyliner.blogspot.com/2022/09/visual-studio-c-linked-dll-exception.html
I have a solution containing my main project and a test project using NUnit. Everything compiles but when I run NUnit I get the exception below after the tests load, and the tests fail. I've added the main project as a reference, and I have $(ProjectDir)bin/Debug/$(TargetName)$(TargetExt) in the arguments for NUnit in the external tools setup, with a blank initial directory.
MyMainProjectTests.Database.TestAddDelete:
System.BadImageFormatException : Could not load file or assembly 'MyMainProject,
Version=1.1.1.0, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. An attempt was made to load a program with an incorrect format.
TearDown : System.Reflection.TargetInvocationException : Exception has been
thrown by the target of an invocation.
----> System.BadImageFormatException : Could not load file or assembly
'ChickenPing, Version=1.1.1.0, Culture=neutral, PublicKeyToken=null' or one
of its dependencies. An attempt was made to load a program with an incorrect
format.
After scouring for hours the only thing I've found is a bug in VS2005 which mentions the /bin and /obj directories, but the answer provided didn't help.
Any solutions?
Instead of setting up NUnit as an External Tool, I set the unit test project as the StartUp project. In the project's Properties screen, set the Start Action to "Start external program" and point it to nunit.exe. In the Start Options section, I specify the test assembly (no path necessary) in the "Command line arguments" box. At this point, simply press F5 to start up NUnit.
Use the nunit-x86.exe instead of nunit.exe as your runner.
A better longer term solution may be to buy ReSharper that includes a much nicer test runner for NUnit that fully integrates into Visual Studio. It auto detects your .NET project type (x68 or x64). ReShaper comes with tons of other features of which unit testing is just one. Their test runner also integrates with their DotCover code coverage analyser.
You may find that you'll need a later version of Visual Studio to use ReSharper. The latest version works with Visual Studio 2013 Community Edition that you can get for free though I understand you may have issues upgrading some project features from such a rather old VS2005 project.
I don't have any affiliation with ReSharper.
Are you running on x64? You will get that error if loading a x64 bit from x86 and vise versa. Also, the path you are trying to create should be the $(TargetPath) macro.
Just set "Platform target" of Tests project to "x86".
Is your main project a .exe or a .dll? Older versions of .NET couldn't reference an .exe, so that might be the problem.
In either case, I'd expect problems if the main assembly didn't end up somewhere accessible by your test assembly (for example, in the same directory). You could check that, and if not make it so, perhaps by having Visual Studio copy the referenced (main) assembly to the local directory.
The "An attempt was made to load a program with an incorrect format." makes me wonder if the "missing assembly" theory is right, but without more info, it's the best guess I can think of.
Go the the NUnit install (example: C:\Program Files (x86)\NUnit 2.6.3\bin) location and open nunit-86.exe.