I've added an unamanaged dll in project OldTesters using Add Existing File.
I've also set BuildAction = Content and Copy to Output Directory = Copy if newer.
I'm using some functions from unmanaged dll in OldTesters project via [DllImport("unamanged.dll")]
OldTesters is .NET project that I've referenced in my main project using Add Reference.
The problem is when I rebuild application everything works fine, but then I close app,
and then click on start, it throws me DllNotFoundException
Unable to load DLL 'unmanaged.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
I've noticed that Visual Studio deleted unmanaged.dll from bin directory.
If I rebuild OldTesters project then it will work. But it is annoying always to rebuild OldTesters, cause I do not add any changes in that project. To prove that, if I click on Build, I will get:
========== Build: 0 succeeded, 0 failed, 6 up-to-date, 0 skipped ==========
because there are no changes in the project.When I run the app I get the same exception.
Although this is VERY old, I just stumbled across the same problem and found the following solution:
just copy all the dlls that are "deleted" to your current project in VS, then they are copied whenever this project is created.
So in your case you just open the project OldTesters, click on the unmanaged dll, copy and then paste it into the project that your other project.
Related
I've just updated my VS to ver. 16.8.3 and now suddenly I am getting this error:
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1720,5): error :
Internal MSBuild error: Non-CrossTargeting GetTargetFrameworks target should not be used in cross targeting (outer) build
Not sure at all what to do about this.
We have been working on this project for years and never had such an issue.
Any thoughts?
Seems that the problem is with projects that use multiple .net frameworks AND they referenence ANOTHER project that uses multiple .net frameworks
I have a MINIMAL sample solution at: my public drive
The solution contains two minimal/empty projects that are technically the same except that the one named Microdesk.DbApp referencing the one name Microdesk.Infrastructure.
The Infrastructure project compiles fine while the DbApp project throws the above error.
This solution was working fine for us for multiple years and broke with the latest VS release 16.8.3
Okay, partially my bad.
I did re-compile the EMPTY sample project and found that despite the compiler error, the solution does build.
1>------ Rebuild All started: Project: Microdesk.BIMrxCommon.Infrastructure, Configuration: Debug2020 Any CPU ------
1> Microdesk.BIMrxCommon.Infrastructure -> C:\Work\Microdesk.BIMrx\bin\Debug2020\Microdesk.BIMrxCommon.Infrastructure.dll
2>------ Rebuild All started: Project: Microdesk.BIMrxCommon.DbApp, Configuration: Debug2020 Any CPU ------
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1720,5): error : Internal MSBuild error: Non-CrossTargeting GetTargetFrameworks target should not be used in cross targeting (outer) build
2> Microdesk.BIMrxCommon.DbApp -> C:\Work\Microdesk.BIMrx\bin\Debug2020\Microdesk.BIMrxCommon.DbApp.dll
========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========
BUT if you try to USE anything from the Infrastructure project in the referencing DbApp project then the Solution will NOT compile
Rebuild started...
1>------ Rebuild All started: Project: Microdesk.BIMrxCommon.Infrastructure, Configuration: Debug2020 Any CPU ------
2>------ Rebuild All started: Project: Microdesk.BIMrxCommon.DbApp, Configuration: Debug2020 Any CPU ------
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1720,5): error : Internal MSBuild error: Non-CrossTargeting GetTargetFrameworks target should not be used in cross targeting (outer) build
2>C:\Work\Microdesk.BIMrx\BIMrxCommon\Microdesk.BIMrxCommon.DbApp\DerivedClass.cs(1,29,1,4
): error CS0234: The type or namespace name 'Infrastructure' does not exist in the namespace 'Microdesk.BIMrxCommon' (are you missing an assembly reference?)
2>C:\Work\Microdesk.BIMrx\BIMrxCommon\Microdesk.BIMrxCommon.DbApp\DerivedClass.cs(5,33,5,42): error CS0246: The type or namespace name 'BaseClass' could not be found (are you missing a using directive or an assembly reference?)
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========
I did upload a second sample project named "Microdesk.BIMrx (2).zip" to the previous OneDrive directory
When I test your issue in your side, I did not face the same behaviors as you described. So I guess that there is some issues on your current vs environment due to the update. And maybe the update broke some tools of VS.
So please try the following steps to troubleshoot it:
Suggestions
1) disable any third party installed extensions under Extensions-->Manage Extensions-->Installed
2) close VS, delete .vs hidden folder, every bin and obj folder of your project.
and also delete all cache files under C:\Users\xxx(current user)\AppData\Local\Microsoft\VisualStudio\16.0_xxx\ComponentModelCache
Then, restart VS to test again.
3) or create a new project and then migrate the content from the old into the new one to test whether the issue is related to your VS or the special project itself.
4) If this does not work, do an initialization operation on your VS.
Close VS, delete the whole user folder under C:\Users\xxx(current user)\AppData\Local\Microsoft\VisualStudio\16.0_xxx and then restart VS to test again.
5) repair vs from the vs_installer
I'm getting this error when running a built project in Visual Studio 2017:
------ Deploy started: Project: myProj, Configuration: Debug Win32 ------
C:\...\myProj.vcxproj : error MSB4057: The target "Deploy" does not exist in the project.
Done building project "myProj.vcxproj" -- FAILED.
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========
I found something online saying uncheck Deploy from Build, Configuration Manager... but it is already unchecked.
If I try to run it again, it will load and run. But I'd like to be able to release code that works the first time. What else might I try? TIA.
Odds are you have a post build event in your project. When you first build it the post build event fires and attempts the deploy. The second time you go to build the project is already 'up to date' so it is not built and the post build event does not fire.
You can view your post build events by right clicking your project and choosing properties, expanding build events and then expanding post build.
You can also check if anything is defined under custom build steps.
Solved the problem by opening the .sln file of the problematic solution with a text editor. I've found there the following lines for different configurations:
{GUID}.Release|x86.Deploy.0 = Release|Win32
After deleting all these lines for different configurations, I didn't get the error anymore.
This worked for me :
GOTO "Project Property Page"
click "Project Dependencies"
Select your main project in "Project:"
Add the dependency on the project that gives you the deploy error.
Save ALL
Recompile
When I try to build the application I get an exception the following exception :
C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(681,3): error : Failed to resolve assembly: 'Java.Interop, Version=0.1.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
I tried cleaning the project and building it again, also updated the Xamarin.Forms packages but still with no luck.
A little overview on the stack trace :
2>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(681,3): error : Failed to resolve assembly: 'Java.Interop, Version=0.1.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
2> Tool /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mtouch execution finished. (TaskId:153)
2> MTouch: 2016-07-05T14:27:15.8191415+05:30 - Finished (TaskId:153)
2> Output Item(s): _NativeLibrary= (TaskId:153)
2>Done executing task "MTouch" -- FAILED. (TaskId:153)
Has anyone received this error? I am running the latest Xamarin for Visual Studio.
As mentioned in the comments above by #SushiHangover Java.Interop.dll is from Xamarin.Android and I was getting an error in Xamarin.IOS.
I had a reference of Mono.Android in PCL which is always referenced in Xamarin.IOS so indirectly I was referencing dll of Xamarin.Android to Xamarin.IOS. Removing the reference from PCL solved my problem.
Step-by-step instructions on how to fish this one out, as it took me some time to find where the 'Android polluted' peace of code was.
Unload your Common code project
Open .csproj look for something like this
<ItemGroup>
<Reference Include="Mono.Android">
<HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v11.0\Mono.Android.dll</HintPath>
</Reference>
Delete this segment from csproj.
Load the project
Clean and rebuild the solution having iOS as startup Project, at this point, you will get a build error that will show which .cs file fails to build due to missing reference.
Go there and move the mechanism to an Android specific project.
As mentioned by #AkashAmin 'Mono.Android' referenced should not be there in PCL project.
But with this, also make sure that you have not added any 'Android' specific code in PCL project by adding 'using Android', if this was done then you need to remove this code by using 'Dependency Services', Click here
I had the same problem and when I removed the android.mono reference from pcl project it worked fine.
I think it happens because we are building project in ios and it doesn't have any android libraries
Platform specific code within the Shared Project will cause iOS compiler to attempt to use the platform specific assemblies when compiling.
In my case, I had a reference within my Shared Project's code, within the "using" statements, which was causing iOS to attempt to link to Android specific assemblies.
Removing the code from the Shared Project allowed for successful compiling of the project.
Just in case, I got this error from working with ReSharper on VS2013 (https://bugzilla.xamarin.com/show_bug.cgi?id=41627).
What I did was use the Workaround to explicitly add java.interop.dll assembly to my project. This problem doesn't affect Build so you can deploy first and VS will download java.interop to your app's obj\Debug\linksrc folder, which you can reference...
You need to check your PLC project on Android link. In PLC project ctrl+f and lets go find "Android" and delete it.
After some changes to my project, Visual Studio started to always re-compiles all sources, causing all dependent project to also re-compile, slowing down development considerably. Why is that?
Happens only when XML documentation file is checked and there's some file with Copy always. If you change either of these, the sources don't get re-compiled.
Happens only when compiling inside Visual Studio - when compiling using MSBuild from commandline, the sources don't get re-compiled.
Visual Studio 2012 Update 4.
This appears to be a bug in Visual Studio, when project has XML documentation file checked some files with Copy always.
Repro:
Create new project - C# class library.
Project Properties => Build => check XML documentation file
Project => Add => New Item => Text file TextFile1.txt
Change TextFile1.txt Copy to Output Directory to Copy always
Right-click project => build
project compiles
Right-click project => build
Expected: Project shouldn't be built, build output should say:
========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
Actual: Project is build, output is:
------ Build started: Project: ClassLibrary1, Configuration: Debug Any CPU ------
ClassLibrary1 -> bin\Debug\ClassLibrary1.dll
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Intestigation: Turning on detailed log, you see:
Target "CoreCompile" in file "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.CSharp.targets" from project "ClassLibrary1.csproj" (target "Compile" depends on it):
Building target "CoreCompile" completely.
Output file "bin\Debug\ClassLibrary1.XML" does not exist.
Looking in procmon, you see that devenv.exe renames "ClassLibrary1.XML" into "vsA381.tmp" just before MSBuild.exe runs. Stack trace for the rename:
KERNEL32!MoveFileW+0x17
csproj!CMoveOutOfTheWayScope::EnterScope+0x85
csproj!CVsProjBuildableProjectCfg::StartBuildProcessWithTarget+0x50b
csproj!CVsProjBuildableProjectCfg::StartBuildProcess+0xc
csproj!CVsProjBuildableProjectCfg::StartBuildEx+0x15
msenv!CSUIBuilder::DoBuild+0x1a3
msenv!CSUIBuilder::Run+0x66
I'm using Vs2010 and Wix 3.6.0917.0, for the record. I use the $(SolutionDir) property quite a bit in my .wixproj file, since I only ever build the installer as part of a solution build or as part of a team build, and never by itself. However, while building from the command line works just fine (both from cmd on the desktop and when building on build agents), when I attempt to reload the .wixproj file into the IDE, I get errors because all the $(SolutionDir) variables are resolving to the project directory, not the solution directory. Consider:
C:\workspace\projectCollection\teamProject\branch\solution.sln
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
and assume a shared custom targets file:
C:\workspace\projectCollection\teamProject\branch\build\shared.targets
which is referenced inside installer.wixproj with:
<Import Project="$(SolutionDir)build\shared.targets">
Command line builds work fine...
C:\workspace\projectCollection\teamProject\branch\> MSBuild /t:build /property:Platform=x64;Configuration=Debug solution.sln
0 Errors
0 Warnings
Build succeeded!
But load into vs2010 and you see...
The imported project
"C:\workspace\projectCollection\teamProject\branch\source\installer\build\shared.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
You can see here that the resolved result of $(SolutionDir)build\shared.targets is getting the project directory and not the solution directory. What gives?
My guess would be that $(SolutionDir) resolves to nothing when the wixproj is being loaded into VS2010. In this case the imported file becomes "build\shared.targets". Since the path is relative it is assumed to be relative to the project directory. Using ".." or some other path could get you around the problem.
I verified this failed with WiX 3.5.2222.0 in VS2010. A C# console application project (csproj) worked as expected.
Have you filed a bug against WiX for this?
I looked at the WiX vs2010 addin code a little bit and the Solution properties are only created when doing a build and not when the project is loaded.