This is the problem. I have been trying to compile a simple desktop vb aplication using the solution task found in nant. When I compile it without crystarl reports controls it compiles ok, but when add a simple crystal report viewer It does not compile any more. I supose I have to make some kind of reference but since these assemblys are in the GAC like System.* assemblys they shouldn't be a problem.
This is the very simple code
<?xml version="1.0"?>
<project name="miPrueba" default="go">
<target name="go">
<solution configuration="debug" solutionfile="simple.sln"/>
</target>
</project>
thanks in advance
So, as I suspected, this was very simple. Here is what I did to fix it. Simply copy the dlls of crystal reports into the bin directory, delete the crystal references in the project, if any,and make the references again pointing to the bin directory.
Related
I am trying to build a NuGet package that includes native DLLs which are to be placed in the output folder when a project uses the package. I have tried to use the several suggestions from this question, but I am always running in the same problem.
My current NuGet package layout is like this:
\build
packageId.targets
file1.dll
file2.dll
\lib
\netstandard1.4
assembly.dll
The contents of packageId.targets is:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<NativeLibs Include="$(MSBuildThisFileDirectory)\*.dll"/>
<None Include="#(NativeLibs)" Link="$(RecursiveDir)$(Filename)$(Extension)">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project>
This should, according to the answers of the other questions, lead to my DLLs being placed in the bin\Debug directory of the project using the package. However, they are not. Instead, they are placed in bin\Debug\packages\packageId\build.
Now I have experimented a lot, and I noticed more and more strange behavior which I cannot make any sense of:
If I move the DLLs to the root of the NuGet package (like one answer suggests) and change the .targets file accordingly, they are not copied at all. There also is no error message.
If I change the .targets file to only reference file1.dll in both Include= and Link=, both files get copied anyway.
So I wondered if some policy just ignores the .targets file and copies whatever is in build to that path in the output folder, but when I remove the .targets file, the DLL files will not get copied anymore.
Now I understand even less what's happening.
What do I need to change to get the DLLs copied right into bin\Debug?
The new way to handle runtime-specific assents in NuGet is to use the runtimes folder to place native assets:
\lib
\netstandard2.0
ManagedWrapper.dll
\runtimes
\win-x86
\native
NativeThing.dll
\win-x64
\native
NativeThing.dll
\linux-x64
\native
libNativeThing.so
\osx-x64
\native
libNativeThing.dylib
If the package is consumed from a .NET Framework project, you may need to add a reference to the Microsoft.NETCore.Platforms package wich provides the runtime graph (runtimes.json) for NuGet to provide proper RID mappings if you don't use base RIDs (e.g. win10-x64 falls back to win-x64 resources).
I am working on two java projects. Project A uses Project B as a referenced library. I need to export my code from both of these projects in a single jarfile. To do this, I created a lib/ folder in Project A and automatically export Project B to that folder. I then automatically export project A with a buildfile like this one, such that all jarfiles in the lib/ folder are included in the final jar:
<?xml version="1.0" encoding="UTF-8"?>
<project name="projectA" default="makejar" basedir=".">
<target name="makejar" description="Create a jar for the project">
<jar destfile="/destination/file/path/projectA.jar">
<fileset dir="bin/"></fileset>
<zipgroupfileset dir="./lib" includes="**/*.jar"/>
</jar>
</target>
</project>
This has been working fine for months. A few hours ago, however, this began exporting only an outdated version of B. I decompiled the code in the lib/ folder and determined that the B export is indeed up to date. However, my decompiled code in the destination file includes an out of date version of B.
I have tried:
restarting eclipse
cleaning/rebuilding all projects
deleting the existing jarfile at the destination
deleting B from lib/, re-exporting B, and reconfiguring my build path for A
Window --> Show View --> Problems
How do I go about diagnosing this problem? Bonus points if you have a better way of managing dependencies so that I won't have to sink ~30% of my development time into stuff like this.
On the off chance that anyone else encounters this, I'll post the solution I found here. I think this was the wrong place to ask this question, but I was getting desperate.
In my question, I give only a heavily simplified version of my setup. In reality, I have 10-some projects, many of which depend on each other.
In this case, the issue was that Project C, which was also part of A's lib/ folder, also depended on Project B. However, I had C closed in Eclipse, so C wasn't being auto-exported. My ant builder, for some reason, allowed C's reference of B to override A's reference to B at compile time.
I intended to use Fody.PropertyChanged in one of my projects, and it was properly added via NuGet:
Install-Package PropertyChanged.Fody
I realized, it was in the wrong project, so I used the uninstall command:
Uninstall-Package PropertyChanged.Fody
After that I added it to the proper project.
Now, when I try to build my solution, I get the following error in the initial project that shouldn't have Fody installed:
Fody: You don't seem to have configured any weavers. Try adding a Fody
nuget package to your project. Have a look here
http://nuget.org/packages?q=fody for the list of available packages.
There is no reference to Fody in the project, I deleted the Fody reference from the packages.config file and there is no XML file.
What else should I do?
You need to also
Uninstall-Package Fody
Remove The "FodyWeavers.xml" and Open the Project file with NotePad or notePad++ and remove the following lines
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<Import Project="..\packages\Fody.1.29.2\build\portable-net+sl+win+wpa+wp\Fody.targets" Condition="Exists('..\packages\Fody.1.29.2\build\portable-net+sl+win+wpa+wp\Fody.targets')" />
I guess you've recently updated the Fody library? When it asked to replace the existing "FodyWeavers.xml" you might have permitted it to do so. If you have a backup of the project, get the "FodyWeavers.xml" from that and replace it with the new one. Clean and Rebuild the solution.
This doesn't specifically address the project you don't want Fody in, but sometimes VS gives vague/odd errors.
I just went through a similar issue after installing PropertyChanged.Fody for the first time, and couldn't build as soon as I included and referenced it... I wonder if any of these details from my experience might help (making sure these points exist in the project you want the lib in).
Make sure you have the following references in your packages.config from when you ran Install-Package PropertyChanged.Fody:
<package id="Fody" version="1.24.0" targetFramework="net45" developmentDependency="true" />
<package id="PropertyChanged.Fody" version="1.49.0" targetFramework="net45" developmentDependency="true" />
Make sure there is FodyWeavers.xml in the top level of the project you want to use it in.
FodyWeavers.xml should look like this (I had to add <PropertyChanged /> to mine)
<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
<PropertyChanged />
</Weavers>
In my ant build I am including a second ant build file (build.xml):
<project name="Including" default="echoC" basedir=".">
<include file="build.xml" as="Included"/>
<target name="echoC" depends="Included.echoB">
<echo>C</echo>
</target>
</project>
build.xml is in the same directory as the including build file and everything is working fine actually. I can run the target echoC and also the target echoB from the included build file is executed first.
What is irritating however is that Eclipse is displaying the error message Target Included.echoB does not exist in this project in the Ant Editor. Does anybody know how to get rid of that?
Thanks a lot for your support!
This seems a bug in Eclipse according to https://bugs.eclipse.org/bugs/show_bug.cgi?id=412809. The comments suggest there is no support for the task in the editor.
Using the import task instead works fine.
I want to deploy my ASP.NET MVC site and have the following script.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\MyProjName\MyProjName.csproj"/>
<PropertyGroup>
<NewInstallDir>C:\DeployFolder\</NewInstallDir>
<BinDir>$(NewInstallDir)bin\</BinDir>
</PropertyGroup>
<Target Name="Build">
<MSBuild Projects="..\MySlnName.sln"
Properties="Configuration=Release;Platform=Any CPU;OutputPath=$(BinDir)" />
<Copy SourceFiles="#(Content->'..\MyProjName\%(RelativeDir)%(FileName)%(Extension)')"
DestinationFiles="#(Content->'$(NewInstallDir)%(RelativeDir)%(FileName)%(Extension)')" />
<Copy SourceFiles="#(None->'..\MyProjName\%(RelativeDir)%(FileName)%(Extension)')"
DestinationFiles="#(None->'$(NewInstallDir)%(RelativeDir)%(FileName)%(Extension)')" />
<MakeDir Directories="#(Folder->'$(NewInstallDir)%(RelativeDir)')" />
</Target>
</Project>
Main idea.
I copied binary to C:\DeployFolder (take structure of folder from sources). I build my dll to C:\DeployFolder\Bin (I don't have this folder in sources folder so I need separately copy this).
I run my script - all works instead of copy DLLs to OutputPath. Same scripts works for other asp.net mvc project. I have no idea what is wrong in this case.
I complete this issue with workaround but I would like to know what is wrong with this script.
The first thing I'd try is to replace your use of the deprecated $(OutputPath) with $(OutDir). From when I've seen this error, 9 times out of 10 it is due to a mismatch between the Platform/Configuration requested and how a particular project is actually defined. Take care to keep track of the discrepency between "Any CPU" (with a space) preferred by solution files and "AnyCPU" actually used inside project files for $(Platform). Some project wizards only set up an "x86" Platform or otherwise omit "AnyCPU" which can cause the OutputPath to be empty.
Beyond that, the approach of importing a project file and then building a solution (presumbably that includes the very same project" is a bit off center. Consider making the deployment changes you desire within the project file itself, through an import. You can either wire into the existing build targets at the right place, or perhaps add an additional target.