I have an application that uses unity and the logging application block. I recent checked-out the application from the repository after these assemblies were added and I got a few error. Eventually I installed enterprise library on my pc and it's now working. My question is do I have to install Enterprise Library on every pc that uses it? If so is there a workaround?
The issue is that your project which references the Enterprise Library assemblies is referencing where the Enterprise Library is installed - probably the Program Files directory. Instead of referencing them there, you could add the Enterprise Library references via Nuget, then check the packages into your source control as part of the project. That way you have the project and its dependencies all in one place, and it shouldn't be necessary to install the Enterprise Library everywhere.
Hi I have no idea how I fixed it. I think that my problem was that I was using the dlls and the config exe's from the enterprise library labs. I should have installed ent lib 5 on my pc. I had the same problem in my ci server so I deleted my project from the repository and added it again as my local was working.
So in a nut shell. Install entlib 5 and don't use the dlls from the labs in your project. I don't need to install ent lib in my deployment all I need is to copy the dlls.
Related
I just upgraded my app to use the latest Microsoft.SqlServer.Types package v14 from v13. This resulted in an well-documented runtime error. The reason here would be missing native libraries:
Spatial types and functions are not available for this provider because the assembly 'Microsoft.SqlServer.Types' version 10 or higher could not be found
The Nuget package also contains the native DLLs that were missing, so I could theoretically copy them to my bin folder and load them through my code, but:
I didn't have to do that with my v13 binaries
When I deployed the updated project to Azure, it ran just fine.
My current assumption would be that I got the v13 binaries with my local SQL install, and on Azure, those binaries (both v13 / v14) are preinstalled.
However, when googling a bit about the issue, most developers have the opposite problem of things not working on Azure due to the missing libs, so I wonder whether not going the manual route might be dangerous with regards to Azure deployments. If anybody had some insight here, that would be awesome!
As far as I know, the azure web service install the SQL server SDK version is 9.0 - 13.0. So you need install 14.0 by yourself.
You could find the dll in the kudu console in your web service.
D:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies>
To open the kudu you could refer to below steps:
1.Find the Advanced Tools in DEVELOPMENT TOOLS click go.
2.Click dubug console's cmd.
3.Find the path.
Notice: You need firstly type cd.. to locate the root path.
You could find the Microsoft.SqlServer file as below:
I have a problem. I recently installed VS 2015 and Windows 10 on my computer.
Having Universal Apps are amazing and I plan to convert some of my programs on UWP.
But I have a problem. In one of my programs, I allow the user to save its datas on its OneDrive. And if OneDrive is unavailable, the datas are stored on local devices.
And when OneDrive is available, the newly stored datas are pushed to OneDrive. Synchronisation in fact.
So it is the problem. In the UWP dll named Universal.Live I have installed Live SDK 6 with Nuget. During the package installation, there is some work done to see if the Live SDK is compatible with UWP.
Great ! It's compatible and successfully installed.
But when I wrote
using Microsoft.Live;
The name is not recognized. And if I use the class LiveAuthClient which is in the namespace, it isn't recognized too...
This is a real problem :( Any ideas ?
I had the same issue adding the Live SDK to my app. For some reason the Package.JSON isn't correctly resolving and downloading the package (or recognizing it).
Either way, just add the DLL to your references the old fashioned way. Personally, I'd just add it to a console app (not using the new Project.json package), get it from NUGET, and grab the DLL from the Packages.
After you have the DLL:
Right click on References
Add Reference -> Browse...
Find the DLL and add it. ("...\\packages[LiveSdk]...")
It works!
Download it from here, Compile it, and grab the desktop SDK:
https://github.com/liveservices/LiveSDK-for-Windows
You can also download the msi, install it, figure out where the DLL is installed to and grab it from there:
https://www.microsoft.com/en-us/download/details.aspx?id=42552
According to this GitHub issue, LiveSDK isn't supposed to be used for Universal Windows Platform apps: https://github.com/liveservices/LiveSDK-for-Windows/issues/58
Instead we should use these SDKs that cover the same functionality:
Mail/Calendar/Contacts: https://dev.outlook.com/
Files/OneDrive: https://dev.onedrive.com/
I have a c# project, that is using nuget-packages, for instance "System.Data.SQLite".
When I build my solution, the project is built each time.
Looking into details, it turns out that the DLLs that belong to packages (that are located in
$(SolutionDir)\packages\$(PackageName)\
) will be renewed before each build, although there is no new version on the server. This results into this each-time-building.
How do I avoid this?
Upgraded nuget.exe to v2.7 solved the problem
I want to implement windows desktop form application having no dependencies to install (e.g. framework, third-party etc).
In which technology I can achieve this?
Can i achieve this goal in C# Win-forms?
You can build an MFC app that requires no installation (just copying the files to the target computer) by statically linking and/or deploying the Visual C++ runtime redist side-by-side.
As Arnon has answered, you can build a .Net app that requires no installation if you target a version of .Net that is pre-installed on your target operating system. This blog entry lists the .Net versions included with each version of Windows.
what version of windows are you targeting your application to ? different versions of windows have different versions of .NET (see this link for details).
So basically, if you are looking for no installation you'd have to shoot for the lowest common denominator and/or ship multiple versions of your app.
I understand that it isn't what you want but -If you do go with .NET it is usually better to ensure that the installer will install the right version of .NET if needed (see this link for example)
I am trying to deploy a Visual C++ application (developed with Microsoft Visual Studio 2008) using a Setup and Deployment Project. After installation, users on some target computers get the following error message after launching the application executable: “This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem.” Another user after installation could run the application properly. I cannot find the root cause of this problem, despite spending several hours on the Visual Studio help files and online forums (most postings date back to 2006). Does anyone at Stack Overflow have a suggestion? Thanks in advance. Additional details appear below.
The application uses FLTK 1.1.9 for a GUI library, as well as some Boost 1.39 libraries (regex, lexical_cast, date_time, math).
I made sure I am trying to deploy the release version (not the debug version) of the application. The Runtime library in the Code Generation settings is Multi-threaded DLL (/MD).
The dependency walker of myapp.exe lists the following DLLs: wsock32.dll, comctl32.dll, kernel32.dll, user32.dll, gdi32.dll, shell32.dll, ole32.dll, mvcp90.dll, msvcr90.dll.
In the Setup and Deployment Project, I add the following DLLs to the File System on Target Machine: fltkdlld.dll, and a folder named Microsoft.VC90.CRT with msvcm90.dll, msvcp90.dll, mcvcr90.dll and Microsoft.VC90.CRT.manifest.
The installation process on the target computers getting the error message requires having the .Net Framework 3.5 installed first.
Any suggestion? Thanks in advance!
Add the Visual C++ Redistributable to your Deployment project and be sure to run Setup.exe instead of the MSI when installing. This will invoke the VCRedist bootstrapper to ensure your PC has those pieces before installing your app.
Dependency Walker only shows static (link time) dependencies - it cannot possibly know about dynamic dependencies such as COM objects.
I had a similar problem after the ATL security updates last year. My app needed a later version of the C++ runtime libraries than the deployment project included.
Try running Windows Update on the target machines after installation, or download and install the latest (28 July 2009) C++ redistributable package directly.
http://support.microsoft.com/?kbid=973551
That solved the problem for me. I haven't fixed the deployment project yet though.