Has anyone ever used NLog 2 with SL5?
I cannot find DLLs for SL5 on the NLog homepage. When I try to reference the SL4 DLLs, VS 2010 says the following:
Why? I thought it is possible to reference SL4 DLLs in a SL5 project (but not the other way round)?
So I checked out NLog sources, opened its SL4 project, changed the target version from SL4 to SL5, Clean, Build and referenced the newly created DLL. While this seems to work it just doesn't feel right.
Any better ideas?
Update: Adding a reference to the original NLog 2 DLLs built for SL4 by directly editing the .csproj file of my SL5 project seems to do the job as well. I'm confused...
<Reference Include="NLog">
<HintPath>..\Libraries\NLog\NLog.dll</HintPath>
</Reference>
Related
This post started out as a question, then I resolved the build issue I was experiencing in a hacky way. I wanted to share my findings for those that may have the same problem and see if anyone has a better resolution. Also, most of the posts I found related to this issue were created when Maui was still in beta. Lastly,
this issue affected the Android build only! The iOS build worked the first time.
Following this Microsoft Maui tutorial, I experienced a build issue right out the gate. The error was APT2260: resource mipmap/appicon and mipmap/appicon_round not found.
In the resources folder there was no appicon_round.svg file, so I copied appicon.svg to appicon_round.svg and tried a rebuild and got the same error.
I deleted android:roundIcon="#mipmap/appicon_round" from AndroidManifest.xml, and deleted the appicon_round.svg file I created via a copy action, but the build still failed.
Even though appicon.svg did exist, I removed android:icon="#mipmap/appicon" from AndroidManifest.xml, and the rebuild was successful. 🤦🏻♂️
Finally, I used Inkscape to create appicon_round.svg, I added it to the projects Resources/AppIcon folder, and then added android:icon="#mipmap/appicon" android:roundIcon="#mipmap/appicon_round" back to the AndroidManifest.xml file. The following build was successful.
First thing to note is that, while Visual Studio 2022 for MacOS did create the appicon.svg file, it did not generate the appicon_round.svg when I created the Multi-Platform project.
The second "gotcha" for me was when I removed the round SVG reference from the Android manifest file, but the build still failed.
A summary of how I resolved this issue is in my answer below. ⬇️
To summarize how to resolved the issue, if you generate a multi-platform project in Visual Studio 2022 for MacOS and any AppIcon SVG files are missing ...
Remove both/all AppIcon references from the AndroidManifest.xml
Build the app.
Generate the missing AppIcon SVG file(s) and put them in the correct folder.
Add both/all AppIcon references back to the AndroidManifest.xml
Build the app.
I'm on a C# UWP gui app, which references a C++ UWP project, which itself uses native dlls (opengl and some others) without referencing them explicitly.
All is working correctly.
But it works only when i add the native dlls to the C# UWP project, and only at the root of the project. Which makes it very messy as there are about 40 dlls.
If i move these dlls in a subfolder of the project, as soon as a C# calls C++, it crashes with a message 'dll or one of its ref ... not found'.
I've already tried that https://social.msdn.microsoft.com/Forums/windowsapps/en-US/26013e5e-3ff1-44a0-8797-0474dabd12d0/uwpincluding-dlls-in-a-uwp-application-in-visual-studio?forum=wpdevelop
Any solution other than creating a post build event or custom msbuild code that copies dlls from the subfolder into the output root folder ?
The reference in the csproj file looks like this:
<Content Include="..\..\..\..\..\..\..\opencv\bin\opencv_features2d411d.pdb" Condition="'$(Configuration)'=='Debug'">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<Link>opencv_features2d411d.pdb</Link>
</Content>
I have an ASP.net MVC 3 project. We're using TeamCity, and up until now everything has checked in fine. All of a sudden today, I did a checkin, and the TeamCity build failed. It said I was missing a using directive or assembly reference and threw a compilation error.
The project on my local machine builds successfully. I rebuilt it several times to make sure. I checked the reference and it's there. I checked the .csproj file and it has the reference there too. I checked bin; it's there. I even RDPed into the server where our site is deployed and checked the bin there, and the dll file is there too.
I don't understand why it's not working, I haven't changed anything in the particular files it says are missing the assembly reference in weeks, I had a successful checkin on TeamCity yesterday, the dll file exists everywhere it's supposed to, and my project builds. I even did a hard reset to the last commit I made that checked in successfully, added my changes back in (which had nothing to do with the reference problem, all my changes were in a .js file), and checked that in, but I got the same compilation error.
Does anyone have any idea what's going wrong, or at least what I might try to resolve this?
edit: There are no path files being used here, the file in question is a .dll file, which I added by clicking "Add reference" on the project. I checked the Github repository and the .dll file is in the bin folder
iamkrillin got me thinking that maybe it was a path issue, so I opened up the csproj file and noticed that the format of the reference to "missing" file was different from all the others around it:
<Reference Include="Ektron.Newtonsoft.json">
<HintPath>..\..\Custom\bin\Ektron.Newtonsoft.json.dll</HintPath>
</Reference>
// THE "MISSING" FILE
<Reference Include="Smdg.Utils, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\NEHGS\bin\Smdg.Utils.dll</HintPath>
</Reference>
I checked the Custom\bin folder and sure enough the .dll file was there (though it also existed in NEHGS\bin), so I got rid of the SpecificVersion tag and changed the path to the Custom folder. TeamCity was able to check it in.
Why it suddenly broke when it's been working for the past 2 months, I have no idea.
I had this just because of not storing NUGET packages at VCS (GIT).
So there is the need to do the restoration of NUGET packages, just before a build step.
https://blog.jetbrains.com/teamcity/2013/08/nuget-package-restore-with-teamcity/
I had the same issue of my TC build suddenly being unable to find an assembly. I solved it by checking in the paths as well. My assembly did not have a tag. Once I added the tage with the path to the dll, TC was able to build successfully
I hope this helps someone out there, in my case I had to check in the folders that had the reference dll/nuget packages. Note that I had already committed the project but for some reason 'SVN' did not check in/ commit the (local) folders that had the dll/ nuget packages so I had to go to the folders and check them in.
I'm trying to build a project with TeamCity Professional 6.5.2
I have a MVC Visual Studio 2010 project using a visual foxpro dll.
The build fails because the dll is not registered.
How can I register that dll in the build machine, as part of the build process?
Thanks!!
There are two different scenarios Rodrigo, your scenario will fall into one of these:
Assemblies which can be referenced by the project: Wherever possible, include dependent assemblies in your source control repository (the 10th Commandment), usually in a "libs" folder which is referenced by the necessary projects. This centralises all your dependencies, makes it easy for new developers to get started and solves your TeamCity build problem.
Assemblies which need GAC installation: There are times when the assembly simply has to be installed in the GAC (i.e. RightFax). Frankly, the easiest thing to do in this case is just to install the damn thing in the GAC. It's an exception and whilst some people will philosophically argue against it, alternatives can get a bit complex (i.e. automating installation as part of the build), and for money I'd rather invest the time elsewhere.
Installing assemblies on each machine (dev, build, prod) will make future updates and any continuous integration system difficult to maintain in the future.
It would be better to create a folder in your working directory (I call it "Resources") which contains a folder for each group of DLLs. Then you just reference the assembly directly from the Project each time. You get duplicate DLLs across different projects, but it keeps everything very clean and simple.
In Visual Studio 2010 you can download a little utility called NuGut which I believes helps to manage assemblies in a better way.
It is a bad idea to register all DLLs on build agent machine, sometime you can find out that you have to install Visual Studio on a build agent machine, for instance ;)
I would suggest to place such libraries along with your code base in Source Control system (I assume you are using it), and just reference lib's folder by declaring a MSBUild property like
<PropertyGroup>
<LibFolder>$(PathFromCommandLineOrJustHardCodedPath)</LibFolder>
</PropertyGroup>
And then before doing a Build/Compile just copy files from $(LibFolder) into the build $(OutputFolder) using standard MSBuild command Copy by specifying source and destination files, and thats it.
To force TeamCity to pickup Lib (dlls) files from VCS folder just add path mapping into the:
TeamCity Configuration Settings -> Edit Build Configuration -> VCS Root settings -> Client Mapping
EDIT:
In your case looks like you have integration test which depends on external COm Server which you need to launch, so you can programatically registr this DLL, for instance in TestSetup, and then do not forget to unregister it in test TearDown.
Anyway you have to just reference this DLL as
VS Project -> Add Existing Item -> Add as Link
+ set
Copy to Output Directory -> Copy if newer
How-To register COM dll: see this SO post
Finally I added a prebuild event in Visual Studio running the regsvr32 command. The dll was in a known location, so I referenced this way:
regsvr32 /s $(SolutionDir)Lib\ProjDataAccess\ProjDataAccess.dll
Agree with Troy Hunt.
For a Continuous Integration with TeamCity 8.0.2 where you need an assembly (custom made shared assembly) reference from GAC, do the following.
1. Add the assembly to the build pack (In my case its nuget package).
2. Before starting the build process (MSBuild, Visual Studio etc), register the assembly to GAC with the help of a command line build runner.
3. Continue with the build process.
By following the above steps, if you are using MSBuild, the build process can link to a valid reference from GAC, which can produce an expected build result.
In my case, where the code refers a custom component from GAC, MSBuild ignored the assembly reference and completed the build process without an exception. But the deployment with the build output failed. To overcome this situation, I've used the give steps.
Note: It is mandatory that the TeamCity agent needs to run under an elevated user account. Else the addition to GAC won't be permitted and the build process can fail.
I was trying to figure out why a debug build was blowing up with the "dependent assembly microsoft.vc80.debugcrt could not be found" event error.
After deleting everything (anything not .cpp or .h) and recreating the solution - I still had the problem.
A google search was fruitless and a re-install of VS didn't produce any change.
I did have the dlls in C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c.
I opened the \debug\.exe.intermediate.manifest file and it had 2 (dependentAssembly) entries:
1st: name='Microsoft.VC80.DebugCRT' version='8.0.50608.0'
2nd: name='Microsoft.VC80.DebugCRT' version='8.0.50727.762'
If I delete one and change the other one to
name='Microsoft.VC80.DebugCRT' version='8.0.50727.42'
I can get a build that will start.
Granted I did have VS2008 installed - but what is controlling the versions ? or How can I get the right debug dll version to "stick".
VS2008 was de-installed through the control panel.
EDIT: Found nothing in the registry if DebugCRT is searched for.
the environment path points to the VS8 folders .
There is only 1 DebugCRT folder in the c:\windows\winsxs\policies folder
(8.0.50.727.42)
The c:\windows\winsxs\manifests folder only has the .42 version of .cat and .manifest
The .manifest file (in above manifest folder) has version="8.0.50727.42"
Clarification: the manifest file has 2 "dependentAssembly" entries each with different versions and not the .42. I can delete 1 entry and change the version on the other to match the .42 to get a debug build that starts.
EDIT2:I'm also using boost and inside the DLLs there is the .762 version
The version was picked up by from the Boost DLLs which were a download, pre-compiled version of Boost. Once the libraries were re-compiled (and re-installed) a re-build of the solution produced a manifest with a single version and the program linked and ran.
So -Check the libs and dlls that are imported into the solution for version used.
VS 2008 is VC90 not VC80, so that's not part of the problem. The relation between manifest-requested assembly and SxS-loaded assenbly is found in C:\WINDOWS\WinSxS\Policies. IIRC, "8.0.50608.0" is generated by VS2005 pre-SP1. It's wrong, and should have been 8.0.50727.42, but this is caught by the policy.
I'm not sure how you're getting two manifests. What are your manifest settings?
I'd suggest rebuilding Boost in your particular environment. Also, you could do away with the Side by Side assemblies altogether by linking the CRT statically...