I took over a Xamarin project that was previously outsourced to a 3rd party. Oh boy, what a nightmare. There is a portable c# project that is refrenced in a separate Android project. Whenever I try to fix the broken reference I'm getting this error message:
Taking a look at the project properties, I can see that there is nothing targeting Xamarin.Android which I'm assuming should definitely be there since this library is clearly being referenced in a Xamarin project. By the way, there is a separate project for iOS that also references this portable library so I'm assuming Xamarin.iOS will also have to be targeted. Completely baffled here all information from Google has been useless.
I have looked at:
https://learn.microsoft.com/en-us/dotnet/framework/cross-platform/portable-class-library
https://lastexitcode.com/blog/2014/11/16/InstallingPortableClassLibrariesForXamarinStudio/
and all related linked in those pages and endless google searches frustratingly obscure topic.
Taking a look at the packages.config I can see these types targeted as well but again have no idea how these are linked to this package.config.
Are my assumptions correct and how on earth can I add these targets?
Related
I have to create app as following.
1- App should work with Android and iOS.
2- Resolution should support to Mobile and Tabs
3- Data storage is on cloud. So, Restful API call will be there for
data transactions
4- There might be local storage for configuration settings
5- There might be native code for some functionalities like implement UrbanAirship Notification, Facebook etc
When I create project for Xamarin.Forms, I get 2 options to create application:
1- Shared, 2- .Net Standard.
I have tried with both. One point is that I haven't found library that contains name like .Shared or .Portable that I have found in one of my old project.
Here is comparision. Please suggest me which type of project I should create for my next project.
Thank you.
At the end it boils down to a matter of taste. The main difference is
shared projects are included in your platform projects as if the source code files were part of the projects themselves
.NET Standard projects are compiled to their own assembly
.NET Standard superseded the portable class libraries. The latter are deprecated and should not be used anymore. There would be no reason for anyway, since .NET Standard is way more convinient and supports a greater subset of .NET (effectively - depending on the PCL profile, but that one compatible with Xamarin was quite limited, e.g. there was very little support for the classes from System.IO).
There are pros and cons both for .NET Standard and shared projects. In shared projects you can use classes directly in your platform projects (anyway, this might be not advisable if you are trying to develop SOLID code), but you'll have to to use #ifdefs to use code that is compatible with only one of the platforms. With .NET Standard you may need to write classes containg platform dependent code twice and load them via DependencyService or - even better - a fully fledged IoC container, but therefor they are much cleaner and concerns are seperated much better.
In the times of PCL there were good reasons to go a hybrid way, e.g. to use System.IO.File from a class that was directly compiled in your platform projects, since both support it, but the PCL Xamarin Profile did not, but with .NET Standard this ain't necessary anymore.
I would always go for .NET Standard libs for the reasons mentioned.
.NET Standard is the future and all plugins and libraries will need to follow and supported it sooner or later.
As in the new prerelease of Xamarin forms 3.0:
We’re now building with .NET Standard 2.0, using the magic of
multi-targeting, while still supporting the PCL profiles and other
.NET Standard versions you may need. Notice how much faster your
projects load when you use .NET Standard project types!
Update To Xamarin.Forms 3.0 prerelease
.NET Standard will provide many features out of the box. Developers are now upgrading their solutions and plugins to support that standard.
.Net Standard. is a new PCL. Use it as if it were a PCL.
My shared project has no packages.config, so where is it storing the packages that it uses?
Also, when I edit references, the tabs are empty - I can't select anything.
What's going on here?
Shared Projects let you write common code that is referenced by a
number of different application projects. The code is compiled as part
of each referencing project and can include compiler directives to
help incorporate platform-specific functionality into the shared code
base.
Source: official documentation where you could find all the details. Beside that there are few related thread on SO, like this one.
P.S.: Official Xamarin documentation nicely covering the code sharing options.
Has there ever been a more confusing/difficult time to be a web developer using the Microsoft stack? That's not really my question... I know that the answer is a categorical no. :)
The single page app template that comes with VS 2013 is deplorable.
I've been working on building up a similar project template that uses Angular JS on the client, but I'm starting to spin my wheels a bit porting over the external (openId/oauth) login features.
I believe this is because of the lack of good, single-point-of-truth, and current documentation for Katana's auth/security bits and also because of how unreadable the client side code is in the S.P.A. template in visual studio 2013.
I know that I can get through it, but while I'm struggling with it, I'm wondering:
Are there any good community provided project templates or example code bases in existence that use .NET 4.5 (MVC5/Web Api 2), Angular JS, the new ASP.NET Identity stuff, and the Katana packages?
There's HotTowel.Angular, but it takes no stance on security. Besides, it's a Nuget package, which can't or shouldn't dictate as much as a proper project template can.
I agree with your observations. I have found the following setup that seems to meet your requirements and I think works very well (I don't have a template), I would suggest the following:
Create an empty WebApi2 project and adopt authentication/authorization depicted here
Use a regular index.html in the base directory as a launching point for your angular application. You can either maintain your client packages with nuget, npm, or bower.
Use whatever technique you like for organization of client code.
Personally, I would create 3 projects, One for client code, (mydomain.com) One for your api (api.mydomain.com) and one for your Model/Repository/Data Access layer.
update
Here is an open-source project that might be what you're looking for!
I have an ASP.NET 4 web application that references a SOAP web service. I have an (old fashioned) Web Reference to this web service in my project. When I compile/build in the IDE I get no problems and Intellisense and the Class Viewer all show me that VS knows what is what and where to find it.
However, when I run the solution, I get this error:
The old CS0234 error (The type or namespace '<...>' does not exist...). Intellisense begs to differ.
My web app assembly is called NovaWeb and my Web Reference is called WS3. I can see that my Reference.cs file contains the following:
namespace NovaWeb.WS3 {
This was all working great a little while ago, but I apparently changed something and now everything is broken. I've tried cleaning out all of the files in the /bin folder and all of the temporary ASP.NET files in my appdata folder.
Does anyone have any suggestions about how I can troubleshoot this problem?
EDIT: My Work-Around...
I've still got the troublesome project laying around in case someone suggests an answer. I can give it a try to see whether a resolution exists. In the meantime, I couldn't wait for a real resolution so I've taken a work-around.
What I've done is started from scratch with brand-new VS2010/.NET 4 web application projects and moved my source code files over into the new projects piece by piece. There are a few salient differences between the busted-down solution (.sln) and the work-around solution. These are:
The work-around has one solution (.sln) per project. The problem solution had two web applications and three EF4 data library projects in a single .sln.
The work-around solution was started from a green field (empty ASP.NET Web Application) template within VS2010 and targeting .NET 4.0 from the outset. The problem solution had parts that began life in VS2008 and originally targeted .NET 2.0.
The work-around project completely avoids any hint of an App_Code folder. The problem solution had a project with an App_Code folder containing a few utility classes. I'm not sure that this makes the slightest difference, but I did run across at least one posting that suggested the compiler might be confused by a code folder called App_Code in a web application project.
"I gave up and started over" is not much of a resolution to a problem, but I thought I would leave it here, along with this question - in case someone happens by with a solution or in case it is at all helpful to the next person with the same problem.
I'm not usually one for answering my own questions. However, this question has been open with no answers for over a month. It's had a decent number of views, which makes me wonder if others might not have the same problem. Since I've finally found the solution, with the help of some direct support from Microsoft, I thought I would document my solution in case it helps the next person to stumble on this error.
So it turns out that web services is a red herring with this problem. The real crux of the issue is the runtime CS0234 error relating to a referenced type. It can also manifest itself as a runtime CS0103 error too, as I found out the hard way.
I mentioned in my question that I found a work-around. The work-around eventually stopped working and I was out of the water on this project. I contacted Microsoft for support and after four days with my source code they came back to me with a solution.
The problem was related to my compiler configuration for target platform.
Due to some agony that I've suffered in the past over deploying multi-assembly applications on the desktop, I have gotten into the habit of changing my build configurations from Any Platform to x86.
This can apparently mess up your compile for an ASP.NET web application. That smells badly like a Visual Studio bug to me, but nevertheless, the solution to my runtime error was to go to the Solution Properties (not project properties) and to select Any Platform for the build target.
I hope this saves someone some aggravation. If anybody has a reasonable explanation as to why this is not a VS bug or what is going on under the covers, I would be interested to hear it and I promise to upvote you for your trouble!
What is the best practice for not breaking builds for team members working on asp.net website code base using TFS?
I keep seeing a single developer adding a reference to get their code to work and checking it in, then when everyone else gets latest version they lack the reference on their dev machines and get broken builds and have to waste time hunting for resolutions.
Aside from emailing the team when someone adds a new reference is there something inherent to VS that can be used?
Can we pull a separate project and refer to that as a redundancy and keep all resource dlls and references there?
The Visual Studio Team Foundation Server Branching Guide 2010 describes many working scenarios. It's long but worth reading.
Guidance for Structuring Team Projects
I've always kept third party DLLs in a project folder under source control, so that a get-latest pulls them down.
Of interest?: Visual Studio 2010 Quick Reference Guidance