Missing (system) assembly references on new project - asp.net

Using VS2015, if I create a new blank project, I get missing assembly reference errors, as shown below:
I haven't touched anything from the initial setup. I can't figure out what's wrong?

I needed to run dnu restore as my dnvm versions were out of alignment.
It's something I really struggle with: I get really confused by all the places where a dnx version needs to be set. Wish MS could make it simpler and/or provide a simple guide/explanation.

Related

The tag 'ChromiumWebBrowser' does not exist in XML namespace 'clr-namespace:CefSharp.Wpf;assembly=CefSharp.Wpf'

I am attempting to add a CefSharp control to an AnyCPU project. I have followed the instructions here: https://github.com/cefsharp/CefSharp/issues/1714 and I thought I had everything working correctly. I pushed my changes to to SVN and then checked out a clean copy.
The first time I attempted to build using that clean copy, I received this error:
error MC3074: The tag 'ChromiumWebBrowser' does not exist in XML namespace 'clr-namespace:CefSharp.Wpf;assembly=CefSharp.Wpf'. Line 18 Position 14.
as a result of this error, several other libraries fail to compile. If I attempt to build again, everything compiles fine.
I ran a diagnostic build, and, it appears that the CefSharp packages are in fact being installed from NuGet prior to this error and, the error occurs during MarkupCompilePass1.
This seems very, very similar to this issue: https://github.com/dotnet/project-system/issues/4158, however, in that case, it sounds as if the problem was resolved by switching from package.config to PackageReference, but, that approach did not seem to fix my error.
I have read https://www.xavierdecoster.com/post/2014/03/06/migrate-away-from-msbuild-based-nuget-package-restore.html as amaintland suggested in the issue I mentioned above, and, unless I'm misunderstanding, it's not a solution that I can use. For the time being, out continuous integration runs on CruiseControl (which isn't mentioned as a tool that supports automatic package restore out of the box), and we're stuck on VS 2013.
Right now the only option that I can find that seems like it might work is checking the NuGet packages into SVN. This is a last resort solution for me, but, lacking a better option, I don't know what to do.
If anyone has any insights or suggested steps, I would really appreciate the advice.

Could not load type 'Sitecore.Reflection.INexusDataApiEx' from assembly 'Sitecore.Kernel,

I am getting this runtime error and can not find anything on the internet around this reference. 'Sitecore.Reflection.INexusDataApiEx'
Any assistance would be greatly appreciated.
Errors like this are usually seen after upgrading or some mismatch in dependencies in your solution. As 'Climber' mentioned, get the zip for a clean version of Sitecore, exactly matching the version you are using (not just "8.1" but also the correct minor update-x version). Verify that your Sitecore.Kernel.dll is the same as the one in the clean version. And verify the other dll's as well (so actually verify the entire bin folder - it should be the same exactly apart from the dll's that came from your own code).
If you have dependencies to Sitecore dll's in your solution (Nuget or otherwise), also verify that they refer to the correct version or you might have the same problem again after a deploy.

Cannot Build Xamarin.Forms From Source Code

I have downloaded the Xamarin.Forms solution from GitHub and I am trying to build the solution. Visual Studio does not build, generating more than 70 errors, as simple as the one below:
"The type or namespace name 'IOnClickListener' could not be found (are
you missing a using directive or an assembly reference?"in
Xamarin.Forms.Platform.Android\AppCompat\ButtonRenderer.cs
When I investigate the code, I see that there is really no reference to Android.Views.View in the using statements, so it seems fair.
Am I making a mistake somewhere?
It's not easy to get to the answer without digging into the logs but here are some steps that have helped me in the past.
Android Specific Steps:
Check the logs for any problems that stand out, look at the top most error first and work your way down. Output window -> Show output from Xamarin Diagnostic
If you find unzipping problems you might have to visit the Xamarin folders to delete the zip causing problems and Xamarin will download a new one.
C:\Users{USER}\AppData\Local\Xamarin
If you get loads of Xaml and Resource errors you might have to delete the contents of the file.
Resources\Resource.Designer.cs
After deleting the content(not the file), clean the solution, rebuild the project.
If you still have problems try to either downgrade Xamarin.Forms or upgrade it.
Change Api level to a higher one on the project properties.
Hope one of these helps.

ParseKit framework in Xcode is red, won't build

I'm trying to add ParseKit to a new command line project in Xcode, but the framework shows as red in the Project Navigator. When I try to build, I get this error
error: /Users/acdlite/Xcode/Chemistry Parser/../parsekit-trunk/build/Debug/ParseKit.framework: No such file or directory
I've followed the directions given by the developer in this answer: How to embed ParseKit as a private framework in a Mac App bundle.
To my knowledge, red indicates that the file is not at the specified location. The file inspector says it should be located at /parsekit-trunk/build/Debug/ParseKit.framework, which actually doesn't exist if I try to navigate there in the Finder. So then where is it located? I have no idea.
I've followed all the steps from scratch like a dozen times now, including checking out the code via SVN. It's driving me crazy, and I feel like an idiot. I wish I could be more specific but I am truly lost as to where to go from here.
Alright, after at least 20 attempts I eventually got it working. Mostly, I followed the steps given by the developer in this answer: How to embed ParseKit as a private framework in a Mac App bundle
However, following the steps exactly didn't work. For the life of me, I couldn't get the ParseKit framework to show up as an option when I attempted to add it as a dependency of my Target. Xcode would just say "No filter results found." So I skipped that step. I also did not add a "Copy Files" build phase. Doing so resulted in a dependency error.
This was way harder than it should have been, and I don't know if that's because I'm stupid or Xcode is poorly designed. Probably a combination of both.
By the way, I'm using Xcode version 4.6.1 (4H512).

Automatic BizTalk Versioning in My Build Process

In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.

Resources