Good Afternoon,
I apologize for the title if it is weird, as I don't really know how to describe this.
To describe my project:
Project has been fine for months
Blazor Wasm project, using Identity Server
Separate Identity grpc service for authenticating logins (hit by Server project piece of the mentioned wasm project)
Both grpc service and wasm use shared organizational nuget packages for identity objects (netstandard libraries)
Key Piece: There are protobuf.net metatype setups for the MSFT dlls that are serialized within Grpc service. E.g. as we cannot set the protomembers for these classes (ClaimsIdentity is one of them, at is the focus of this issue) The metatype setup is to expose the necessary properties to both client and service...
Recently, wasm was updated to net7
When deployed, the metatype setup for ClaimsIdentity blows up, stating that the field "Label" cannot be found. App doesn't run, fails within Program.cs...makes sense...so far...
Now, first thing I did was switch to the dev branch, pull latest, etc. Run locally, don't get the same issue; no issue at all actually, ran without any problems. Do "Go To Definition" and see the Label field within the ClaimsIdentity class (netstandard).
After updating VS, rebuilding, etc... I push out a pacifier release so people can test (removed the ClaimsIdentity line as the wasm piece doesn't need it, we're just reusing a helper method that had it in there). I then go back and try the Go To Definition stuff again, this time, I'm directed to the 7.0.0.0 dll of System.Security.Claims. The class is definitely different than the netstandard one (why I'm now sent to this definition, I dunno, I suspect caching of code/dll I dunno, whatever). Still, I cannot duplicate the issue when debugging.
At this point, after seeing that I'm getting different files on my own machine. I decided to use ILSpy and see if the deployed System.Security.Claims dll is the same....it is not. It is also System.Security.Claims v7.0.0.0, but only has a _label, private property.
Easy fix is just to remove the line throwing causing the issue, but, that is superficial. I'd like to know what I'm missing in why I'm seeing different contents between net 7 dlls. I'm thinking I'm overlooking something dumb, actually, I hope that I am.
Image: Left is Locally Built, Right is what gets deployed (both being Azure Devops and manual publish)
Related
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
The kpm pack command needs the runtime for the server - is it possible to install windows runtimes on osx just for the pack and deploy?
Ok, it seems that in order to recognise that the deployment is an aspnet vNext project and to handle that as a 'ProjectK Web Application deployment', you have to make it look like it all came from Visual Studio (or at least that was the only way I managed to get it to work right now)...
I did this by taking an example one from somewhere else...
I took a simple single vnext web project .sln file and changed the project name and project GUID.
I took the .kproj Visual Studio project file and did the same.
There isn't much that needs to be changed - only the name of the project and GUID. It's nice that there isn't any file lists in there so I feel that this might end up as a once-only activity...
I did find that there are some project structure rules that seemed to make it break. You seem to have to have the sln file in the top level folder and a folder underneath for the web project. If there is ONLY a web project then this might seem overkill, but I tried collapsing everything up to the top with the sln file correctly pointing, but that didn't work.
The other thing that you need to make sure you have is a reference to "Microsoft.AspNet.Server.IIS" in the project.json dependencies. Without this, the AspNet.Loader.dll and bin folder don't get deployed.
Apart from that, I am now able to use Sublime Text (or whatever I want on osx), test using "k kestrel", checkin through git and it gets deployed automatically to an azure web site! yippee!
Actually this makes much more sense because it is letting the target decide upon the binaries it needs to satisfy the deployments. Next challenge might be to get it to pull 'my' libraries from a custom NuGet source to get my binary libraries in there and avoid uploading ALL of the source to the website!
Oh - and another tip: Quit kestrel with 'Enter' for a clean quit instead of Z which leaves the port listening but non-functional!
I have a MVC 4 web project that I have been working on for about a year. It is currently published and running on azure in production, and has been working there for about a year. My dev machine malfunctioned and I had to replace it. After setting up my dev environment and retrieving my codebase from my repository, I made a very minor change to one of my pages (I corrected a typo, changing "teh" to "the" in the text of one of my .cshtml pages. I downloaded and imported my azure publish profile settings from:
https://windows.azure.com/download/publishprofile.aspx?wa=wsignin1.0
which seemed to correctly populate my publish dialog and I attempted to publish my correction to staging. However, when it builds prior to publish, the output window starts to show a series of "the type or namespace {x} cannot be resolved" errors. It accumulates 72 such errors for various referenced assemblies, and then it exits with "build failed".
A few seconds later all those errors disappear and if I rebuild the solution, it does not give me those errors, which ONLY appear on a pre-publish build. I can run the project in testing environment and it works fine there.
I have tried everything I can think of. Has anyone ran into this before?
After a week of frustration, I finally figured out what was happening. I had a email library, rebex, that I had purchased that the project used. It was installed on my original development machine, where the application was publishing correctly. The .dll file for the rebex library was incorporated into my source code so that when my new dev machine was configured and the source code restored, the .dll file was present, and worked in development mode.
However, it would not publish to production until the installation file was re-downloaded and the rebex assemblies were registered to VS2012 and the GAC.
If anyone else has this issue, check to see if you have purchased or licensed libraries that need to be properly registered.
MSD
Here's the scenario: I have multiple developers on an asp.net mvc 4 project. Each developer has a local database. The source control system is TFS at http://tfs.visualstudio.com. We're using Azure websites to host the site. We have also configured Azure websites for continuous deployment.
The source control system could be git, mercurial, TFS, etc. Honestly, I don't think it matters.
My question is how to accomplish these three things:
Each developer has his/her own connection string(s) locally (without them being in source control)
Azure has its own connection string(s) (without it being in source control)
Source Control doesn't show any connection information
The ability for each developer to F5 and run/debug/test the app locally.
We accomplished #1 by adding our individual connection strings to our machine.config so that there's no conflict between developer workstation setups.
I originally removed the connectionstrings section from web.config. In the Azure website (using the management portal, under Configure), I configured the connection strings, and after watching a Scott Hanselman video was under the impression that these would be dynamagically merged into my web.config upon deployment, but that doesn't appear to happen. Whenever I go to any page that hits the db, I get an error saying can't find the connection string (or some other db error related to the connection)
If I put the Azure connection string directly in web.config, Things work on Azure, but then the connection details are in source control visible to everybody.
After reading some more posts from Scott and David Ebbo it seems that I could put a blank connection string in web.config (with the correct name) and then Azure will overwrite the values correctly. I would then have to have the developers put their connection strings in their web.debug.config and then install the Slow Cheetah plugin so that they could F5 and test locally. They would also have to not check in the web.debug.config into source control. (Not that easy with TFS) This seems like a seriously burdensome kludge, that's bound to fail somewhere along the line.
I have to believe that this isn't that rare of a problem. How do other teams accomplish this?
After looking around, it appears that what I was asking isn't actually supported without a bunch of command line hacks to the pre/post build process. What we ended up doing is forcing developers to all create their own local databases, use trusted authentication, and establish a SQL alias that was used by all developers in the web.config. That way, it works locally for everybody, it doesn't expose any user names/passwords within source control, and Azure can still overwrite it when automatically pulled from source control.
Slow Cheetah is actually a nice solution. It's an extension to web.config transformations. Those transformations let you keep one web.config file and then for each deployment scenario you specify which changes you want to it. For example, your Release configuration will probably remove the debug attribute.
This can also be used to change connection strings. The transformations are applied during the deployment of your project to Azure.
What I've done in the past to make this also work with local development machines is use a web.config with an externalized connections.config file. Each developer created a connection.machinename.config file that was copied to connection.config on build in the post-build step. Those files don't have to be checked in and they can never cause conflicts because each machine name is unique.
The release/staging/.. configurations used a web.config transformation to replace the connection string element with a specific connection string for that deployment (and that way remove the dependency on the external config file).
Slow Cheetah offers some nice helpers for checking the result of these transformations at design time.
Scenario:
In my organisation, we separately develop multiple applications. In the end however, many of the applications (and their databases) are deployed to the same SQL instance, so they share the same master database.
We use Visual Studio 2010 database and server projects to source control said databases.
To try and standardise some things, I want to do the following:
Create a 'Core' Server database project which has all the server settings, core logins etc. Things like SET TRUSTWORTHY ON and server-level ANSI settings etc.
Have each Application's own Server.dbproj specify the logins and roles etc specific to that application.
Have each Application's own ApplicationDatabase.dbproj reference the ApplicationX.Server.dbproj
In theory, each Application in source control would only contain the items specific to it, rather than keeping server related settings or configuration synchronised across many projects.
Problem
However, in practice I can get this far:
Done. Produces a .schema file which I reference in future steps
Done. Server.dbproj happily references Core.dbschema and 'extends' it with it's own logins and roles etc. Is happy to deploy this anywhere I point it.
Nadda. I add a reference from ApplicationDatabase.dbproj to Server.dbproj (assuming Server would pull in the items from Core) and it complains about any logins that are actually in Core.
So I then added both Server and Core as references to ApplicationDatabase as it settled down. Compiles fine.
However, when you deploy, you get the same problem described here: http://social.msdn.microsoft.com/Forums/uk/vstsdb/thread/23cb9132-00d4-42ed-b34c-ab49027cddf7
Error TSD01234: The source model contains 2 server option elements.
Only one element can be contained in a model that can be deployed
The problem I think is that ApplicationDatabase essentially has two Server projects that it knows about, and therefore duplicate settings.
Microsofts documentation makes no mention of using partial projects in Server projects, but neither is it listed as a limitation.
So the question is...
Has anybody used partial projects successfully for Server projects, or is there a way you can see to achieve the same thing?
I'll be honest and say I won't just 'remove the Server projects' to make the problem disappear - we had it working very well up until I tried to improve things!