I have a solution that contains 2 webjobs projects in it. The solution was developed on one machine using VS2015. I recently upgraded the solution to VS2017. Both of the webjobs projects have WindowsAzure.Storage v8.1.1 installed on it. There are also 2 other projects in the solution that have WindowsAzure.Storage v8.1.1 installed.
This solution is saved in TFS.
On a second, freshly built machine with VS2017 installed, I fetched a copy of the solution from TFS. Many of the references from Nuget were not found. After some time, I was able to refresh all the Nuget package for the solution. All but WindowsAzure.Storage v8.1.1. The only version that will install on the new machine is v7.2.1. When I try to upgrade the solution to v8.2.1 it simply fails and rolls back. I'm not getting any indication what it's failing on.
The other 2 projects that are using v8.1.1 install fine on both machines. It seems that the issue is only on the webjobs projects.
The 2 webjobs projects are targeting different platforms. One is targeting 4.6.1 and the other is targeting 4.5.2.
I've been working on this for several days now. Since I don't seem to be any closer to solving the problem, I decided to ask the question here.
I'm thinking I'm missing an install of something, but I'm not getting enough feedback from Nuget to let me know what I'm missing.
Related
For a long time opencv has been (and still is,) the main infrastructure for 2d development.
When going 3d, PCL is the natural choise: it has vast range of algorithms implemented, online API documentation, and the backbone of the industry's leading companies.
That said, How can it be that the last binary is for IDE 5 years ago?(!!!) last update was in 2013 (probably due to the death of OPENNI, thank you Apple), the implementation is obsolete , and I am not even talking about c++1x, nevertheless the futuristic compute capability 5.x.
Is PCL a dead project? are there's any predecessors?
I too work with PCL and find the outdated libraries frustrating. However as PhilLab mentioned the GitHub page is still active.
HOWEVER: Thanks to Tsuksa Sugiura there exists a perfect pre-built package for Windows + VS2015. He even maintains this and updates it. Both x86 and x64.
ALSO it is possible to use 1.8.0 RC2 on the NVidia Tegra platforms, such as the Jetson TX1. here the CMake system is working relatively well.
AND ROS supports it (again defaults to 1.7.2, but can run on 1.8.x)
So to conclude; sure no one is packing it into tidy releases, but the package is slowly getting advanced. And it kind of is our only choice...
Also to the moderators: I would have commented this on PhilLab's answer as I feel this doesn't dignify a new answer... but on this strange community you can answer before being able to comment. Sorry.
I share your frustration with the outdated prebuilts (outdated both in IDE version and PCL version) but the project is still quite active on GitHub: https://github.com/PointCloudLibrary/pcl/commits/master.
The release cycle seems to be quite lengthy but the commits come in steadily
Edit: Release 1.8.0 is in preparation and the lack of Windows builds is because the lack of a Windows programmer
Edit (06/2018): The newest versions include windows prebuilds
Now the best option to use PCL on windows is using the vcpkg package management system to manage the dependencies and binaries.
I've recently made a Windows Forms Application in VS 2010 Express. When running on my machine it works fine but on other machines it needs to install the .NET framework first. Is there anyway around this? By including the library in my executable? By not using the .NET framework?
I would really appreciate some help.
Typically this kind of problem would be handled by your Windows Forms Application's installation package.
Opinions vary but I'd suggest the safest/most polite thing to do is to treat .NET as a prerequisite. If .NET is not present, display a message that it is required before the install will succeed and perhaps point to a Microsoft download page like this one or this one. The risk is that you point them to an obsolete download page or that the page moves and invalidates your link.
That said, I would have expected most machines to have some version of the .NET Framework installed (by Windows Update for example) so it's a bit surprising that you're being told it needs to be installed.
I suggest you follow the instructions in How to: Determine Which .NET Framework Versions Are Installed to check one of your failing machines to confirm that .NET is not installed (very unlikely) or to determine which version (or versions) of .NET is (are) installed.
Update 6/21/2015 From the comment below, we have evidence of two systems without .NET installed so my "very unlikely" comment above is a bit off base!
Update 7/4/2015 I have a bad habit of forgetting that not everyone configures their Windows systems exactly the same way I configure mine. From this blog post it seems that the .NET Framework is 'only' a Recommended Update.
I have some code here that we used to use to call a Python script from our (very large) application. It worked fine when we used VS2008 (compiler v90), which is what the default version of python27 was compiled with.
In the last year we've upgraded our application to VS2010, and I was looking to update the Python-calling dll, thinking it would be a morning's work. Unfortunately, after wrestling with the linker and missing dlls for ages, most of my colleagues agree that our application and python27.dll are using incompatible versions of Windows CRT.
I thought it would be simple enough to find a version of python27.dll (or indeed another version would be fine) compiled with VS2010 (v100) - but I can't.
Is there a way to call a Python script from an application compiled in VS2010?
An answer may be: Download the python sources - compile a custom python.dll and link against that.
I have the same problem. The solution is indeed to build python from the sources. But there is a big drawback: all extra 3rd party python modules pre-build for Windows that you download from internet will not work! This is because all of those modules will be prebuild with VS 2008 and you get again in trouble with incompatible runtimes. The solution is that all such extra modules needs to be again rebuild from sources, but the task is not easy in all cases. The modules are ususally tested in VS2008 and you get a lot of troubles trying to run them with VS2010. I got this mostly with database connectors for MySQL, MSSQL and others.
I am trying to install CppUnit on Windows.
I have downloaded it from here, decompressed it, and noticed that all files have ,v in their name, and no extension.
The instructions for installation (in included files, as well as on every site I found that suggests installation for Windows, are for Linux. (example installing CppUnit for Windows Instructions).
Others, just to build: (example: installing CppUnit for Visual Studio Instructions or Second answer on same topic).
The accepted answer on the above link has a comment saying that the person who accepted it "Sorted it, I downloaded another version" - after he had exactly the same problem as I did - but did not specify what version or from where...
The link I have above is the latest version.
I was able to find a very old version, 1.12.1, from 2008, that would almost build (with lots of errors), on Windows. I am using it now to learn how to implement CppUnit. Still, it is 4 years old... I would like to be able to use the latest build...
Please, can someone give me some suggestion that I can implement, and works, in Windows, to install the latest cppUnit ?
Thank you.
The first download you made is an archive of the CVS repository. This explains the strange ,v "extensions" you see on the files. It is not what you should download. And indeed, the correct download you made (version 1.12.1) is 4 years old. It was the latest stable version though, so it should normally build. I don't know what the exact problems were you encountered.
There are however two newer options. There is CppUnit2, which is available here. And there is an independent fork of the original project available here.
Perhaps you can check either of those out and see if they are less problematic for you.
The fork Bart mentions on freedesktop.org appears to be the (only?) continuation of CppUnit version 1, and at this moment has version 1.13.2.
Note that for this version, if you want to use the test runner on Win64, you'll have to make a small modification described here until that has made it to a newer release.
I'm unable to do a scenario from subject.
I have DirectX 9 March 2009 SDK installed, which is 9, "sub"-version c, but "sub-sub"-version is 41, so libs (d3dx9.lib d3d9.lib) are linking exports to dxd3d_41.dll.
What happens when I try to run my app on machine which has DX9.0c but not redistributable from march 2009 is now obvious :), it fails because it cannot find dxd3d_41.dll.
Which is standard solution for this problem?
How Am I supposed to compile my app to be supported by all machines having DX 9.0c?
Is that even achievable?
Thanx
You need to install the runtime that matches the SDK you use to compile.
The only way to force this to work on ALL machines with DirectX9c installed is to use an old SDK (the first 9.0c SDK). However, I strongly recommend avoiding this. You are much better off just using March 09, and install the March runtimes along with your application installation.
The simplest solution is to link to the Microsoft DirectX end-user runtime updater on your download page and tell people to run this first to make sure that the runtime components are up to date before installing your application.
After that, the next simplest thing is to bundle the necessary runtime updater with your application and have users run it before running your installer.
All of this is documented in the SDK documentation.
The rules are that if you link to d3dx9 then you are expected to handle making sure that the required redist runtime components are installed.
Have a look at the page 'DirectX Installation for Game Developers' in the DXSDK docs.